This isn't yet official, as the version of ActiveInbox that complies with this document is still undergoing approval from Google. We will announce on the blog when this goes live.
Sensitive Data Transit and Storage
- We use SSL (https) everywhere, for secure data exchange between your machine, our server(s) and Gmail.
- The data in the database is encrypted to the outside world, and is protected within the Amazon Web Service's ecosystem. Our development employees have access to the data, but are under contract to only be allowed to temporarily access it with your explicit consent (e.g. to fix a problem).
- Our server does not contain user's Gmail email data, nor the OAuth tokens to access it. Thus no personal data is accessible to a rogue employee, or any attackers in a compromise.
- As an EU company we're subject to the GDPR, and we only store the limited PII required to fulfil ActiveInbox's functionality.
- Our server is broken up by purpose, so if any one is compromised, the others aren't also exposed.
- ActiveInbox uses OAuth tokens, rather than requiring your Gmail password. Users can see and revoke tokens for specific applications at any time. The ActiveInbox team can also remotely revoke these tokens within 2 hours, should a system wide compromise be discovered.
- Commencing mid 2019, we'll be undergoing ongoing world-class penetration testing to look for vulnerabilities as part of Google's own mandate to remain a published app.
Known Potential Weaknesses
- The sub tasks and notes you add with ActiveInbox are stored in plain text on our server, creating an additional risk of exposure of sensitive information. (See Future Improvements).
- The OAuth token, which grants the ActiveInbox client access to your Gmail data and is refreshed at least every hour, is refreshed via our server, leading to the conceptual possibility of interception (see the Attack Vectors below).
- Our mobile app stores a user's OAuth token, with full access to their Gmail data, on our server. (See Mobile Caution below).
Defence Against Anticipated Attack Vectors
An employee attempts to read your emails
Your data is not stored anywhere readily accessible by our employees. We do not have the means, from our database, to access your emails. Our client does not send email data to our server. The only caveat is if you enable Send Later, your email IDs are stored on our server, but they contain no personal data.
ActiveInbox's servers are hacked
Our servers are broken into small components, so the breach of one is less likely to reveal all data.
Even though the OAuth token is refreshed via our server, it's not stored there. An attacker (external or internal employee) would need to replace our code to achieve this, and then transmit the data out to a 3rd party service. Revisions to our code are tracked by version control.
Commencing mid 2019, we’ll be undergoing ongoing penetration testing to look for vulnerabilities.
One of our developers, acting rogue, alters the code to upload your data to a server
Code changes are reviewed by our founder, prior to publishing of a new version. Nobody else has the power to publish an update. This reduces the scope of trust to an individual with a major financial incentive not to lose that trust.
All our code changes are tracked in revision history. Even if the developer subverted the code review, it could be uncovered.
You would spot the data being uploaded to api.activeinboxhq.com in Chrome’s Network tab (or in your internet/proxy logs, if you have such software installed).
The employment contract explicitly specifies the illegality of this. The consequences are trivial to prosecute.
An employee’s laptop is stolen (or any other form of privileged accessor data loss)
We have shared team guidelines to handle this, rapidly locking down any compromised system.
Our server database does not contain a user's email data, or the means to access to their data via Gmail. There’s little to compromise.
If the attacker altered ActiveInbox’s code to upload your sensitive data for their use, they’re still extremely unlikely to be able to publish it via the Chrome Web Store to affect actual users. Only our founder, Andy, has access to the Chrome Web Store (which even if it was his credentials that were compromised, still requires re-login after a very short period of inactivity, and the password is not stored in any password manager). And the Chrome Web Store takes from 30 minutes to an average of 8 hours to publish the changes, in which time we could have locked down the compromise, halting the publishing process.
A user is phished into loading a clone of Gmail, tricking ActiveInbox into interacting with it
Unless the hacker managed to also mimic Gmail’s URL, which is theoretically impossible, ActiveInbox will not attempt to interact with a website that merely looks like Gmail.
Even if it did, we don’t inject sensitive data into Gmail, so the spoof couldn’t steal data. At worst, it could read the subject lines of your task emails via the fake Gmail DOM, and trigger ActiveInbox to add labels to your emails by simulating clicks to ActiveInbox's buttons. That’s a worst case scenario, and still theoretically impossible (as in the previous paragraph).
Another extension tries to steal your OAuth token from ActiveInbox within Chrome
This isn’t possible in Chrome’s security architecture (ActiveInbox stores the token in the background page, that only it can access).
Malware comprises a user’s computer, to steal the OAuth token
It would be in the form of a virus, which is an event we can’t easily guard against.
It would need to targeted to the precise nature of ActiveInbox’s storage mechanism to know how to extract the token.
A malware author, if they compromise your machine, would have much more success with a broader attack - spoofing Chrome and reading data as you access Gmail or your bank, phishing to get your login details, extracting all documents from your computer. I.e. this is just a catastrophic event we can’t easily protect against it, but is relatively unlikely.
We also believe that by storing the powerful OAuth token on your local machine, you're statistically less likely to be compromised than if we store everyone's OAuth tokens on our server. That's because if they reside on our server, they become an attractive target to hackers who could gain access to everyone's email account with a single attack. Whereas on your local machine, it's one attack per one credential.
As with any compromise, if we become aware of such a malware attack, we can invalidate all OAuth tokens issued granted to ActiveInbox within 2 hours of discovery, preventing further abuse.
Nonetheless, we are considering not storing your OAuth token to the file system so it's even harder to steal, but with a usability trade off. Please see Future Improvements'.
A completely unforeseen compromise occurs, theoretically granting access to your email
Gmail still tracks unusual behaviour occurring via the Gmail API, and would report this to you in the Security panel.
We track unexpected location changes for data access, including OAuth token refreshes, using your IP address. This is a very revealing signal that a 3rd party is attempting access.
In customer support, we listen for telling signs from users that their account has been compromised: emails unexpectedly sent from their accounts, passwords reset in other services, blackmail threats, etc.
We also respond to the ethical disclosure from independent security researchers, and pay bug bounties if they identify a vulnerability.
If any compromise is believed to have occurred, we can revoke all Gmail tokens granted to ActiveInbox within 2 hours, to prevent further data leakage after first discovery.
A Caution Regarding Our Mobile App
We're in a transition phase for ActiveInbox. Our browser addon (aka 'desktop ActiveInbox') has been overhauled to utilise the security principles described here, but our mobile app still needs to be updated.
The main difference is that the OAuth token, that grants full access to Gmail data, is stored on our server. The original design decision for this was to provide push notifications for new emails, but we can achieve it with a lesser scope (that only provides metadata, not email bodies).
This OAuth token is only at risk if we're hacked, as employees are contractually denied access to the data, but nonetheless you may wish to not use our mobile app depending on your organisational security requirements. We'll announce on the blog when this change is complete.
Possible Future Improvements
- Ideally, Gmail will produce a new OAuth Scope, that lets ActiveInbox add/remove labels without accessing the email bodies. If such a scope existed, it would dramatically reduce the risk associated with the OAuth token being stolen. If you agree, you can add a comment to raise its profile on Google's issue tracker.
- ActiveInbox could stop storing the OAuth token on a users local file system, reducing the chance for malware to steal it. But it comes with the trade off of having to log into ActiveInbox each time. (Please talk to us if this is a pressing priority for you, we may be able to create a bespoke solution.)
- ActiveInbox could start encrypting the Sub Tasks & Notes a user adds to their email. The trade off is there will be no way to recover the notes if the user forgets their password. (Please talk to us if this is a pressing priority for you, we may be able to create a bespoke solution.)