Security

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

Summary

Known Potential Weaknesses

Defence Against Anticipated Attack Vectors

High Confidence

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

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

Lower Confidence

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