Hacker News Reader

Comment by DoubleMalt | Hacker News Reader

This is really great news. But even better would it be if they'd incorporate it directly in gmail with a polished user interface.

View on HN

No it wouldn't be better. You'd just have yet another LavaBit that claims ultimate security but has no teeth. The private keys must never touch the DOM, whether it comes from Google's servers or put there by an extension, otherwise it's vulnerable to someone hijacking/NSL-ing the gmail session.

Therefore something must be installed on the local computer, whether that means a Chrome extension that has access to localStorage (like this project) or some standalone app.

If you're worried about UX, it looks like this project is meant to interface with gmail specifically, and extensions are able to alter the experience so I imagine it will be reasonably easy to use.

Well the threat model would rather be that Google is forced to serve a version of JavaScript to you that leaks your private key. Which is a concern and a reason why you should rather use a self hosted email client like Mailpile.

If you are concerned about someone hijacking the gmail session you have lost anyway, as the decrypted (or not-yet-encrypted) text surely has to hit the dom at some point.

<infogulch> is correct. I wrote about this in 2007:

http://news.cnet.com/Will-security-firms-detect-police-spywa... "In theory, government agencies could even seek a court order requiring security companies to deliver spyware to their customers as part of an auto-update feature. Most modern security companies, including operating system makers such as Microsoft and Apple, offer regular patches and bug fixes. Although it would be technically tricky, it would be possible to send an infected update to a customer if the vendor were ordered to do so."

Countermeasures to autoupdates include: (a) disabling them; (b) verifying that the checksum you receive is the same as posted on a number of different sites unlikely to be coerced into delivering FedGov malware; (c) only downloading autoupdates from a non-U.S. repository unlikely to be coerced into delivering malware. And probably many others I'm not thinking of offhand.

But in reality if your threat model is that the NSA/FedGov/FBI/GCHQ/CIA are already targeting YOU SPECIFICALLY, you probably already have a few dozen physical bugs that were concealed in your home placed via a sneak and peak Scarfoesque black bag job the last time you went out for pizza. A hypothetical court order to force FedGov malware on you specifically via autoupdates can be contested by the provider (I was the first to report last May that Google was litigating two non-malware NSL cases pre-Snowden) and in any case is not bulk surveillance.

I agree that such a thread model makes things difficult, however I'd like to believe that it can be solved for. Regardless, there is value in hiding your communications from mass, non-targeted surveillance.

If you're able to completely "solve for" the threat model of NSA/FBI/GCHQ/CIA/etc. having a serious and persistent interest in you, and knowing where you sleep at night, my hat's off to you. Few people are that confident.

I never implied that I could! Anyway, my comment was concerning communications. Physical security is another matter. I must have missed that portion of your OP.

In this project, even if Google is forced to serve a compromised version of Gmail's javascript they still can't get your key, since it's stored in the browser's localStorage and is private to the extension, where all the crypto happens. All gmail gets is the end result.

So the threat model for this project is autoupdates. Extension autoupdate, chrome autoupdate and OS autoupdate could all compromise this, but that's still worlds better than just sending some different obfuscated javascript in a browser session.

Encypt it offline, copy paste the encrypted text+signature into the GMail compose window. Unencrypted never hits the DOM (unless the recipient has an extension that decrypts in the DOM).

It would be better.

There's nothing that says Google can't bundle the extension with Chrome, and require Chrome or the extension on Firefox to use encrypted Gmail.

End-to-End is better outside Gmail. Because it is an extension, you can encrypt/decrypt any message in any webpage such as: web forums, other web mail providers (yes even Yahoo Mail, Outlook.com, etc), or your custom internal SquirrelMail or Outlook Web Access instance, etc.

Its open source can be reviewed by third parties, it can be built and installed locally, with no dependency or trust placed in Google's online services. Heck, it can even be (in theory - I never tried) installed on Chromium if you are paranoid and don't trust the few non-open source parts of Chrome.

> it can be built and installed locally

Google has made this a fucking nightmare. Every time you start Chrome, you get an annoying popup "do you really want to enable local extensions blah blah"

Reply on news.ycombinator.com