Live data from Hacker News

End-To-End – OpenPGP Chrome extension from Google

code.google.com

61–70 of 173 posts

Re: End-To-End – OpenPGP Chrome extension from Google

#61
post #11

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?

It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.

Re: End-To-End – OpenPGP Chrome extension from Google

#62
Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message. When done it replaces the contents of the textarea on the site with the signed/encrypted message.

It works quite nicely, and I like it. I would like to see some kind of keybase integration, though it's not hard to import my tracked users into the extension by exporting my gpg keyring and importing it again.

edit: It seems that the keybase website does not like messages created by this extension. https://github.com/keybase/keybase-issues/issues/752

Re: End-To-End – OpenPGP Chrome extension from Google

#63
post #41

Earlier quoted context omitted.

Does this also mean parts of memory containing, say, passwords could be send to Google?

This "end to end" encryption happens in the browser. Google is the browser. Google dont need your keys, they have the plain text.

Also, other browser extensions may be able to access what is going on in the browser. So Google and (insert list of other parties.)

Re: End-To-End – OpenPGP Chrome extension from Google

#64
post #11

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?

There is one textarea, and the contents of that get installed.

Re: End-To-End – OpenPGP Chrome extension from Google

#65
Regarding JavaScript crypto:

  We hold ourselves to a higher standard; we started from scratch
  and created a testable, modern, cryptographic library.
That is awesome. So's this:

  Chrome’s design means that extensions should be safe against
  other extensions.
And this:

  End-To-End uses Content Security Policy as well as inherently
  safe APIs in frameworks (strict Closure Templates). End-To-End
  doesn’t trust any website's DOM or context with unencrypted data.

Re: End-To-End – OpenPGP Chrome extension from Google

#66

Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message.…

But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it.

In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?

Re: End-To-End – OpenPGP Chrome extension from Google

#68
post #14
post #11

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?

Why would attachments be considered part of the body? Encrypt them before uploading them, and send the decrypting key in the body.

Regardless of how e-mail protocol transfers attachments, GMail pre-uploads files to their servers when composing an e-mail, so if you want to encrypt them, you'll need to do it beforehand.

Re: End-To-End – OpenPGP Chrome extension from Google

#69
post #14

Earlier quoted context omitted.

Why would attachments be considered part of the body? Encrypt them before uploading them, and send the decrypting key in the body.

> Why would attachments be considered part of the body? Because if you look at the low-level structure of email, "attachments" are just parts of a body that is in multipart/mixed MIME type.

If you look that low, the body isn't actually encrypted, just the parts of it that contain your data.

Answering the GP, that varies from one implementation to another. Most clients encrypt attachments, but it looks like this one extension only encrypts the textarea contents.

Re: End-To-End – OpenPGP Chrome extension from Google

#70
post #66

Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message.…

But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it. In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?

In the FAQ they mention "End-To-End doesn’t trust any website's DOM or context with unencrypted data. We have tried to ensure that the interaction between the extension and websites is minimal and does not reveal secrets to the website."

I'm curious about this too. Does that mean they somehow insert a textbox that the host page can't see? I didn't realize extensions could do that.

Edit: ah, this appears to be where it happens. They insert an iframe the extension owns, so the host page won't be able to see what's in it:

https://code.google.com/p/end-to-end/source/browse/javascrip...

Post reply on HN