The security story will definitely be better once we have the plugin, but it's already quite good. So under the current read-only OAuth model: - Tokens can onl

The security story will definitely be better once we have the plugin, but it's already quite good. So under the current read-only OAuth model: - Tokens can only be used from our servers, and their use is logged by both us and Google - Tokens are rate limited on Google's end, both per user and per app. Both of these combine to make any sort of large scale breach essentially impossible. We also don't access and store any email messages until you've already chosen to publish them, and even then they're stored encrypted unless they're publicly accessible. (E.g. the remain encrypted if not everyone gives permission or if you're publishing with a private repository.) I filed a feature request ticket with Google asking them to log when an app accesses a full message, so that way we can prove that we aren't accessing any emails except the ones you choose you upload. So we'll see if that gets added. We also have very extensive tests for everything privacy and security related on the back end, which helps. The main thing to note is that we're explicitly not designed to be a platform for whistleblowers. One of the design decisions we made is to associate threads with email addresses rather than usernames. This is useful because it let's people give permission or anonymize themselves without first making an account, and then later have their threads associated with their account. Great for usability, but it also means that if you want to be an anonymous whistleblower there are other platforms that are better suited for that. Anyway once we have the Gmail Add-on, that will make it so we only have read-only access to the currently active thread where you activate the add-on. It's only a couple weeks of work, right now I'm just hoping we can get Google to add a couple more API wrappers so that we don't need to write any new code to parse threads.