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 or Calendar 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 (website, API, stats), 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.
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 stored on your local machine (see the Attack Vectors 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 that 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.
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 uploads of data to our server are validated to conform to a schema, in a single module of code. This simplifies our QA process before publishing an update, making it difficult fo a rogue employee to slip in code that uploads Gmail data.
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 api2.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.
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.
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.
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.)
- 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.
Bug Bounty Programme
We actively wish to work with the whitehat security community to harden ActiveInbox. If you'd like to attempt to find weaknesses in our system, please see the Bug Bounty for how we will reward you.