51–60 of 173 posts
Isn't this contrary to Google's goals as an advertising business? If people are using end-to-end encryption, they won't have cleartext emails to mine, &c. I need to wonder what the catch is, because there is definitely one: does Google own all the keys, or does Google secretly own all the keys?
If it is a chrome extension and is installed via the Chrome Web Store, it can be updated silently in the background if I'm not mistaken. So in theory, wouldn't it be possible to serve Google with a NSL and force them to silently push a modified update to a targeted user that reveals the private key?
The FAQ states: > Only the body of the message. Please note that, as with all OpenPGP > messages, the email subject line and list of recipients remain > unencrypted. Hopefully attachments are considered part of the body?
I don't think so. PGP scrambles the text of the message for you (that's the body), but you're still using the standard email protocol, which sends attachments without making changes to them. You'd need to encrypt the files before sending them. (And the recipient would have to unencrypt them manually.)
[0] http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
[1] http://msdn.microsoft.com/en-us/library/ms526560(v=exchg.10)...
I'm not saying that End-To-End does this, just that it is perfectly possible (and common) to encrypt the whole message.
H
So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e-mail encryption. That's annoying.
Isn't this contrary to Google's goals as an advertising business? If people are using end-to-end encryption, they won't have cleartext emails to mine, &c. I need to wonder what the catch is, because there is definitely one: does Google own all the keys, or does Google secretly own all the keys?
The keys are generated by you, stored on your browser's localStorage, preferably encrypted (their words, not mine). Since it's open source and distributed by Google, I bet many eyeballs will look for bugs, much more than alternatives such as Mailvelope or WebPG. So, no, I don't think Google will ever have access to your private key through this mean.
My theory:
- We're talking about PGP. This will only impact geeks.
- Google prefers keeping the trust of said geeks by willingly revoking its capability to read their conversations. One of the primary support of Google success is said geeks, and it wants to keep it that way.
- PGP only encrypts the body of an email. The header (ie the metadata) is still here for Google to collect, in plaintext
Earlier quoted context omitted.
Maybe encryption/decryption could be performed in a separate, isolated process, which stack would never be sent? It seems like Chrome multiprocess architecture could allow for this.
Under "JavaScript crypto has very real risk of side-channel attacks": End-To-End’s crypto operations are performed in a different process from the web apps it interacts with.
"Please note that enabling Chrome’s "Automatically send usage statistics and crash reports to Google" means that, in the event of a crash, parts of memory containing private key material might be sent to Google." I hope that has more than a FAQ warning when they release it to the Chrome Store. Otherwise....:/ It isn't perfect but it is probably the best in-browser option given the constraints available.
"Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself." So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e…
"Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself." So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e…
"We’re releasing this code to enable community review; it is not yet ready for general use."