11 ms·

An Update to End-To-End

142 points by aarkay 12y ago

jMyles 12y ago
I mean, this seems just straight amazing, right? Am I missing something? Obviously Google is pivoting on a number of fronts; if this enjoys wide adoption (unlikely as that may seem at the moment), they'll have to basically retreat from email content analytics, right?
- lallysingh 12y ago
  Perhaps the additional user trust is worth it? But the other cost is searchability, which is a pain for a search-based email system. I don't think many people use labels very much.
  - avz 12y ago
    Considerable value of the search functionality can be retained by restricting it to metadata like originator which needs to be accessible for delivery to work anyway.
    - lallysingh 12y ago
      I completely agree. I'm curious on what's lost on the tail, however. Then again, I don't find many things that way, anyways.
    - comex 12y ago
      For me at least, this would be completely unacceptable as a search replacement, as I frequently search old message bodies. Not to mention that there's no reason originator can't be encrypted at rest, at least in theory.. However, based on the experience of desktop search, I think pure client side search would probably have reasonable initialization time and space overhead, and would certainly make searches faster, at least compared to my current Gmail experience.
      - Animats 12y ago
        For me at least, this would be completely unacceptable as a search replacement, as I frequently search old message bodies. ... However, based on the experience of desktop search, I think pure client side search would probably have reasonable initialization time and space overhead, and would certainly make searches faster, at least compared to my current Gmail experience. Just install Mozilla Thunderbird and use IMAP. Client side search, all your devices sync via IMAP, no ads, and free software.
        comex 12y ago
        FWIW, I've evaluated email clients from time to time, but haven't found anything I like enough to replace Gmail. I haven't tried Thunderbird for years because I don't want to use a client without conversation view, and Thunderbird doesn't seem to offer it as a core feature; I could try one of the extensions for it, but I'm suspicious it won't work well. Also, I'm not sure I want to start using a product that's been on life support for two years. However, I admit these are relatively small turnoffs, so perhaps I should give Thunderbird a spin some time... Anyway, it's off topic.
        jesrui 12y ago
        > I don't want to use a client without conversation view, and Thunderbird doesn't seem to offer it as a core feature Actually it does, sort of: Right click on you@example.com, choose Search Messages, then Save as Search Folder, then "Match all Messages" and, in "Select the folders to search", Inbox and Sent.
  - quonn 12y ago
    Probably. They make most of their money on Google search anyway - and with just the queries, no personal context as far as I know. No privacy issues arise here, in fact, it would probably work in incognito mode just as well. Are there any numbers on how much profit they actually make on Google Mail?
  - cromwellian 12y ago
    Not just searchability, auto-categorization, and anti-spam as well. I would view it through the lens of putting the power of choice in the hands of the user. It allows people to make the choice of whether they value privacy more than usability, or, it allows fine-grained control -- end-to-end for messages you care to keep private, but no encryption for the mails you don't care about, but want searchability (mailing lists, notification emails, package tracking, etc)
    - lallysingh 12y ago
      Indeed. I hadn't thought of spammers looking up your public key somewhere and sending you an encrypted email with it.
      - x1798DE 12y ago
        You could always use white-listing for encrypted e-mails - refuse all encrypted e-mail not from people on your contacts list or people whose keys you've signed, etc.
- notatoad 12y ago
  The emails that it is useful to do analytics on and the emails that it is useful to encrypt aren't the same emails. The valuable emails to analyze for a company who sells targeted advertising are the transactional emails - booking confirmations, purchase receipts, etc so they can build up a profile of what your habits are, and it is incredibly unlikely that anybody is going to start encrypting those. The email you send your boss updating him on the latest project status, or a personal email to your parents don't have a lot of marketing value.
  - keville 12y ago
    > booking confirmations, purchase receipts, etc But these are _exactly_ the things I, the user, want encrypted. I would probably even stop doing business with vendors that did not encrypt their transactional communications with me.
    - passionfruit 12y ago
      Perhaps those of us that prefer encrypted email should begin lobbying companies to encrypt transactional emails.
- josho 12y ago
  I felt the same as you, until I read that Google is going to manage your keys or handle the cert. authority part (however that ends up). Then I realized their end game, which is to control end to end encryption adoption to keep another vendor from controlling it. It's the same strategy google did with the browser and mobile. They don't want to be locked out of this play, because if they don't have influence then they may potentially loose all sorts of profiling data on you. So, with Google controlling the adoption they can ensure mechanisms to provide services around your encrypted data to benefit you (while also serving google by letting them into your encrypted life).
  - timothya 12y ago
    Unless I'm reading this wrong, according to the End-to-End docs, it looks like keys are kept in a "Key Directory", and that Google will run one Key Directory, but you can use whatever Key Directory you want. I haven't seen evidence that Google will have any access to your unencrypted data.
- DrJosiah 12y ago
  You don't need to analyze content on the Gmail server to get content analysis to the Gmail server (if that is necessary at all). If Google's primary intent is to make sure that users keep their email encrypted completely, smart clients (like browsers and mobile apps) can do what Gmail servers can't. Look at what the Google-provided Gmail Offline extension does. Now remember that End-to-End is just an extension, like Gmail Offline, except that this one also decrypts email on the client. Once email is decrypted on the client, analysis can be performed (like indexing the email for search), and that analysis can be sent to the Gmail servers or used to perform ad calls directly (I'm not saying that Google is doing this, but technologically all of this is pretty easy given everything else already done).
- rakoo 12y ago
  My bet: End-to-End encryption, not even automatic but through the use of a plugin, will only appeal to the niche of people who are concerned about that and may not be using GMail. For the most part of its user base, nothing will change. Things will start to move for the majority when end-to-end encryption can be done directly in the protocol, by default, i.e anything but email.
higherpurpose 12y ago
I hope they don't work too hard to making it compatible with PGP (and probably shouldn't at all). Just through Gmail and Yahoo alone adopting it, the end-to-end encrypted e-mail user base could increase by 100x. So it makes little sense to make it backwards compatible, especially if that creates potential security issues.
- lallysingh 12y ago
  One of the benefits of PGP is that it's stood up pretty well to the test of time. Incompatible changes would be a little suspect, from a security perspective.
  - higherpurpose 12y ago
    PGP's lack of forward secrecy seems like a major flaw, unless they can somehow make it easier to have the benefits of PFS while keeping the current design. But didn't they already say they intend to use elliptic curve keys instead of RSA for much better performance? Wouldn't that already break compatibility with PGP? The only real downside I see from breaking PGP compatibility is that then the new system will need a few years before it can really be "trusted". However: 1) it already won't be very trusted since it happens in the browser, and it will be quite hard for Google to absolutely guarantee without a shadow of a doubt that they can't change any settings themselves (even though they own the Chrome browser and the Chrome store, on which the extension will live). 2) being new doesn't mean it can't be better. We already have better secure messaging crypto protocols such as Axolotl, so it is possible to make one that's both new and better. (I actually wonder why we can't just use Axolotl for an email interface, and call it a day?!).
    - unethical_ban 12y ago
      Forward secrecy on PGP? So I can't go read my old love letters?
      - mjevans 12y ago
        Forward security typically means you make it possible, after the session is complete, for anyone to have said anything during the session. Thus making it possible for any potential log of said session to be forged and presented as 'evidence'; therefore implying that even a log which happens to exist on someone's computer is in fact forged (or more to the point, that any potentially recovered log or monitored log is forged; even if an identity has signed off on the session key). So if 'PFS' was used with a sent message then anyone/everyone would be able to read or forge the message. This is not the problem that PGP/OpenPGP was designed to solve.
mrsteveman1 12y ago
Given that they've already decided to include support in Chrome itself for accessing USB hardware security tokens for U2F, I see no reason why they couldn't do the same with End to End + OpenPGPCards like the Yubikey NEO, which happens to also be a U2F device. It would provide a solution to some of the issues they document on their own Wiki regarding secret keys being stolen by an attacker through another Chrome extension, another application on the system, etc. EDIT: YES! I missed this part[1] in the Wiki earlier: "Additionally, we plan to add remote private key support in the future. When support for that is ready, high-risk users could protect their secret keys (stored, e.g., in a hardware USB device) from compromise even when an adversary introduces a backdoor in the source code." [1] https://github.com/google/end-to-end/wiki/Threat-model#backdoor-in-end-to-end-source-code https://github.com/google/end-to-end/wiki/Threat-model#backd...
sft 12y ago
I wish they would stop calling it End-to-End, it's misleading, they don't talk about DNS at all. One weak link in the chain means the entire chain is weak.
- notatoad 12y ago
  DNS is not relevant at all here. Your email is encrypted client-side at one end, and decrypted client-side at the other end. At no point in between does it exist in cleartext. If there is some DNS vulnerability that causes your email to get intercepted, that in no way compromises the encryption.
  - sft 12y ago
    Here? Where is here? The blog mentions nothing about email specifically.
    - notatoad 12y ago
      Whatever. "here" is any text encrypted by this module, whether it is the body of an email or something else. The data isn't getting decrypted mid-stream, it goes from one client (or "end") to another. It is end to end encryption, and DNS has nothing to do with it.
driverdan 12y ago
Can anyone who has been using End to End provide some feedback and additional info about it? The docs (and blog posts) don't really say much other than it encrypts text.
deleted 12y ago
[deleted]
jmnicolas 12y ago
> We’re migrating End-To-End to GitHub A bit off-topic but it seems to me that Github is fast becoming a "too big to fail" actor.
- nullspace 12y ago
  The switching costs away from Github is trivially low actually. You may lose out on some of the niceness related to github - but there are plenty of good git based source code hosting software out there.
  - k-mcgrady 12y ago
    The only pain point in switching I can think of is issues/wiki. Are they exportable from GitHub and importable into something like BitBucket?
    - icehawk219 12y ago
      The wiki is just a Git repository so you could just clone that and then do what you need to with it. Once it's cloned locally I'd imagine it's fairly straight forward to either manually copy it to something else or use an API to copy the files up to a wiki somewhere. For issues GitHub has great API coverage for fetching them [0] so I'd imagine it's not terribly difficult to write a migration script. There are already ones out there for going from BitBucket to GitHub [1] so the reverse should be possible. [0] https://developer.github.com/v3/issues/ https://developer.github.com/v3/issues/ [1] https://github.com/vbabiy/bitbucket_issue_migration https://github.com/vbabiy/bitbucket_issue_migration
  - jmnicolas 12y ago
    I should have been more clear about what I meant : I was thinking of failing as in downtime not the company being bankrupt. Imagine a cyber-attack that would paralyze Github for one month ...
Fastidious 12y ago
How could a regular user start using this (unless it is not ready at all for the "fearless ones")?

142 points by aarkay 12y ago

I mean, this seems just straight amazing, right? Am I missing something? Obviously Google is pivoting on a number of fronts; if this enjoys wide adoption (unlikely as that may seem at the moment), they'll have to basically retreat from email content analytics, right?

lallysingh 12y ago
Perhaps the additional user trust is worth it? But the other cost is searchability, which is a pain for a search-based email system. I don't think many people use labels very much.
- avz 12y ago
  Considerable value of the search functionality can be retained by restricting it to metadata like originator which needs to be accessible for delivery to work anyway.
  - lallysingh 12y ago
    I completely agree. I'm curious on what's lost on the tail, however. Then again, I don't find many things that way, anyways.
  - comex 12y ago
    For me at least, this would be completely unacceptable as a search replacement, as I frequently search old message bodies. Not to mention that there's no reason originator can't be encrypted at rest, at least in theory.. However, based on the experience of desktop search, I think pure client side search would probably have reasonable initialization time and space overhead, and would certainly make searches faster, at least compared to my current Gmail experience.
    - Animats 12y ago
      For me at least, this would be completely unacceptable as a search replacement, as I frequently search old message bodies. ... However, based on the experience of desktop search, I think pure client side search would probably have reasonable initialization time and space overhead, and would certainly make searches faster, at least compared to my current Gmail experience. Just install Mozilla Thunderbird and use IMAP. Client side search, all your devices sync via IMAP, no ads, and free software.
      - comex 12y ago
        FWIW, I've evaluated email clients from time to time, but haven't found anything I like enough to replace Gmail. I haven't tried Thunderbird for years because I don't want to use a client without conversation view, and Thunderbird doesn't seem to offer it as a core feature; I could try one of the extensions for it, but I'm suspicious it won't work well. Also, I'm not sure I want to start using a product that's been on life support for two years. However, I admit these are relatively small turnoffs, so perhaps I should give Thunderbird a spin some time... Anyway, it's off topic.
        jesrui 12y ago
        > I don't want to use a client without conversation view, and Thunderbird doesn't seem to offer it as a core feature Actually it does, sort of: Right click on you@example.com, choose Search Messages, then Save as Search Folder, then "Match all Messages" and, in "Select the folders to search", Inbox and Sent.
- quonn 12y ago
  Probably. They make most of their money on Google search anyway - and with just the queries, no personal context as far as I know. No privacy issues arise here, in fact, it would probably work in incognito mode just as well. Are there any numbers on how much profit they actually make on Google Mail?
- cromwellian 12y ago
  Not just searchability, auto-categorization, and anti-spam as well. I would view it through the lens of putting the power of choice in the hands of the user. It allows people to make the choice of whether they value privacy more than usability, or, it allows fine-grained control -- end-to-end for messages you care to keep private, but no encryption for the mails you don't care about, but want searchability (mailing lists, notification emails, package tracking, etc)
  - lallysingh 12y ago
    Indeed. I hadn't thought of spammers looking up your public key somewhere and sending you an encrypted email with it.
    - x1798DE 12y ago
      You could always use white-listing for encrypted e-mails - refuse all encrypted e-mail not from people on your contacts list or people whose keys you've signed, etc.
notatoad 12y ago
The emails that it is useful to do analytics on and the emails that it is useful to encrypt aren't the same emails. The valuable emails to analyze for a company who sells targeted advertising are the transactional emails - booking confirmations, purchase receipts, etc so they can build up a profile of what your habits are, and it is incredibly unlikely that anybody is going to start encrypting those. The email you send your boss updating him on the latest project status, or a personal email to your parents don't have a lot of marketing value.
- keville 12y ago
  > booking confirmations, purchase receipts, etc But these are _exactly_ the things I, the user, want encrypted. I would probably even stop doing business with vendors that did not encrypt their transactional communications with me.
  - passionfruit 12y ago
    Perhaps those of us that prefer encrypted email should begin lobbying companies to encrypt transactional emails.
josho 12y ago
I felt the same as you, until I read that Google is going to manage your keys or handle the cert. authority part (however that ends up). Then I realized their end game, which is to control end to end encryption adoption to keep another vendor from controlling it. It's the same strategy google did with the browser and mobile. They don't want to be locked out of this play, because if they don't have influence then they may potentially loose all sorts of profiling data on you. So, with Google controlling the adoption they can ensure mechanisms to provide services around your encrypted data to benefit you (while also serving google by letting them into your encrypted life).
- timothya 12y ago
  Unless I'm reading this wrong, according to the End-to-End docs, it looks like keys are kept in a "Key Directory", and that Google will run one Key Directory, but you can use whatever Key Directory you want. I haven't seen evidence that Google will have any access to your unencrypted data.
DrJosiah 12y ago
You don't need to analyze content on the Gmail server to get content analysis to the Gmail server (if that is necessary at all). If Google's primary intent is to make sure that users keep their email encrypted completely, smart clients (like browsers and mobile apps) can do what Gmail servers can't. Look at what the Google-provided Gmail Offline extension does. Now remember that End-to-End is just an extension, like Gmail Offline, except that this one also decrypts email on the client. Once email is decrypted on the client, analysis can be performed (like indexing the email for search), and that analysis can be sent to the Gmail servers or used to perform ad calls directly (I'm not saying that Google is doing this, but technologically all of this is pretty easy given everything else already done).
rakoo 12y ago
My bet: End-to-End encryption, not even automatic but through the use of a plugin, will only appeal to the niche of people who are concerned about that and may not be using GMail. For the most part of its user base, nothing will change. Things will start to move for the majority when end-to-end encryption can be done directly in the protocol, by default, i.e anything but email.

higherpurpose 12y ago

I hope they don't work too hard to making it compatible with PGP (and probably shouldn't at all). Just through Gmail and Yahoo alone adopting it, the end-to-end encrypted e-mail user base could increase by 100x. So it makes little sense to make it backwards compatible, especially if that creates potential security issues.

lallysingh 12y ago
One of the benefits of PGP is that it's stood up pretty well to the test of time. Incompatible changes would be a little suspect, from a security perspective.
- higherpurpose 12y ago
  PGP's lack of forward secrecy seems like a major flaw, unless they can somehow make it easier to have the benefits of PFS while keeping the current design. But didn't they already say they intend to use elliptic curve keys instead of RSA for much better performance? Wouldn't that already break compatibility with PGP? The only real downside I see from breaking PGP compatibility is that then the new system will need a few years before it can really be "trusted". However: 1) it already won't be very trusted since it happens in the browser, and it will be quite hard for Google to absolutely guarantee without a shadow of a doubt that they can't change any settings themselves (even though they own the Chrome browser and the Chrome store, on which the extension will live). 2) being new doesn't mean it can't be better. We already have better secure messaging crypto protocols such as Axolotl, so it is possible to make one that's both new and better. (I actually wonder why we can't just use Axolotl for an email interface, and call it a day?!).
  - unethical_ban 12y ago
    Forward secrecy on PGP? So I can't go read my old love letters?
    - mjevans 12y ago
      Forward security typically means you make it possible, after the session is complete, for anyone to have said anything during the session. Thus making it possible for any potential log of said session to be forged and presented as 'evidence'; therefore implying that even a log which happens to exist on someone's computer is in fact forged (or more to the point, that any potentially recovered log or monitored log is forged; even if an identity has signed off on the session key). So if 'PFS' was used with a sent message then anyone/everyone would be able to read or forge the message. This is not the problem that PGP/OpenPGP was designed to solve.

mrsteveman1 12y ago

Given that they've already decided to include support in Chrome itself for accessing USB hardware security tokens for U2F, I see no reason why they couldn't do the same with End to End + OpenPGPCards like the Yubikey NEO, which happens to also be a U2F device. It would provide a solution to some of the issues they document on their own Wiki regarding secret keys being stolen by an attacker through another Chrome extension, another application on the system, etc. EDIT: YES! I missed this part[1] in the Wiki earlier: "Additionally, we plan to add remote private key support in the future. When support for that is ready, high-risk users could protect their secret keys (stored, e.g., in a hardware USB device) from compromise even when an adversary introduces a backdoor in the source code." [1] https://github.com/google/end-to-end/wiki/Threat-model#backdoor-in-end-to-end-source-code https://github.com/google/end-to-end/wiki/Threat-model#backd...

sft 12y ago

I wish they would stop calling it End-to-End, it's misleading, they don't talk about DNS at all. One weak link in the chain means the entire chain is weak.

notatoad 12y ago
DNS is not relevant at all here. Your email is encrypted client-side at one end, and decrypted client-side at the other end. At no point in between does it exist in cleartext. If there is some DNS vulnerability that causes your email to get intercepted, that in no way compromises the encryption.
- sft 12y ago
  Here? Where is here? The blog mentions nothing about email specifically.
  - notatoad 12y ago
    Whatever. "here" is any text encrypted by this module, whether it is the body of an email or something else. The data isn't getting decrypted mid-stream, it goes from one client (or "end") to another. It is end to end encryption, and DNS has nothing to do with it.

driverdan 12y ago

Can anyone who has been using End to End provide some feedback and additional info about it? The docs (and blog posts) don't really say much other than it encrypts text.

deleted 12y ago

[deleted]

jmnicolas 12y ago

> We’re migrating End-To-End to GitHub A bit off-topic but it seems to me that Github is fast becoming a "too big to fail" actor.

nullspace 12y ago
The switching costs away from Github is trivially low actually. You may lose out on some of the niceness related to github - but there are plenty of good git based source code hosting software out there.
- k-mcgrady 12y ago
  The only pain point in switching I can think of is issues/wiki. Are they exportable from GitHub and importable into something like BitBucket?
  - icehawk219 12y ago
    The wiki is just a Git repository so you could just clone that and then do what you need to with it. Once it's cloned locally I'd imagine it's fairly straight forward to either manually copy it to something else or use an API to copy the files up to a wiki somewhere. For issues GitHub has great API coverage for fetching them [0] so I'd imagine it's not terribly difficult to write a migration script. There are already ones out there for going from BitBucket to GitHub [1] so the reverse should be possible. [0] https://developer.github.com/v3/issues/ https://developer.github.com/v3/issues/ [1] https://github.com/vbabiy/bitbucket_issue_migration https://github.com/vbabiy/bitbucket_issue_migration
- jmnicolas 12y ago
  I should have been more clear about what I meant : I was thinking of failing as in downtime not the company being bankrupt. Imagine a cyber-attack that would paralyze Github for one month ...

Fastidious 12y ago

How could a regular user start using this (unless it is not ready at all for the "fearless ones")?