Security

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.

Our servers are broken into small components, so the breach of one is less likely to reveal all data.

Even a complete compromise cannot leak your sensitive email data. Because under the GDPR, we minimise the PII data we store on the server (see our Privacy Policy); and we do not store OAuth token access keys to your Gmail data in our server database.

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.

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.

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).

This isn’t possible in Chrome’s security architecture (ActiveInbox stores the token in the background page, that only it can access).

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.

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.