8 ms·

I would love if Google did this, but I see two significant problems. 1. Who stores my private key? Google? Chrome? Both seem troublesome 2. "Also, Google woul

I would love if Google did this, but I see two significant problems. 1. Who stores my private key? Google? Chrome? Both seem troublesome 2. "Also, Google wouldn’t be able to scan and index the text of your e-mails. That’s a problem if you need to search for old emails not stored on your own machine. It could be a real issue for Google’s business model as well, which involves scanning the text of emails in order to place contextual advertising." Unclear that Google would give up arguably their greatest personal data asset (better than search, imo), which of course is the key to their whole business model.

Thirdegree 12y ago
In response to 2) I would say the best way (from Google's perspective) would be a way to flip a switch on a per-email basis. So by default, emails aren't secure, but if you need it you can activate it. I wonder if the loss of data would be worth the increase in users though.
- higherpurpose 12y ago
  > I wonder if the loss of data would be worth the increase in users though. I think that's the wrong way for Google to look at it. The question should be "how many users will I lose if I don't enable something like this in my services soon?" The best thing American companies could do right now, especially large ones like Google, to make sure regions like Latina America or Europe don't take a "you have to build your datacenter here" stance and make things much more expensive for them, is to ensure that the data is private, even if it's on American servers, because they've adopted trustless protocols, and even they can't see what's inside. That's what's going to stop users and institutions from other countries from bailing on American corporations like Google. So losing a little data signal from the ad tracking data is hardly a big loss in comparison, and could help Google regain at least some of the trust they lost post-NSA revelations.
  - saraid216 12y ago
    > I think that's the wrong way for Google to look at it. The question should be "how many users will I lose if I don't enable something like this in my services soon?" Since this answer is "an insignificant amount", I think you'd be happier if Google looked at it the wrong way.
    - higherpurpose 12y ago
      Insignificant only when you look at the way things work right now. This is the problem with monopolies such as Comcast, too. They think "hey why bother improving the service, and cost us money, when we're not going to lose customers to anyone anyway"? That only works when there's no competition or the competition isn't serious enough. But as soon as something like Google Fiber comes out, they start freaking out, because they know customers have developed a lot of resentment towards them when they kept thinking "why bother improving the service?", and they will quit them as soon as a much better alternative is available. The same can happen to Google, too. Imagine if this was Microsoft coming out today and saying they are going to implement PGP or something even better for true privacy - and imagine then they would do campaigns like Scroogled and Gmail Man. Now do you still think it's a mistake for Google to do this from a strategic point of view, so they don't lose customers in the future? If Google wants Gmail to remain the #1 e-mail service, then they need to do such moves first, not as a reaction to other competitors. Because by then the exodus may be too hard to reverse, if the perception of Google's services becomes much poorer and they've lost most users' loyalty (not necessarily the users themselves up to that point - but the loyalty of those users).
      - saraid216 12y ago
        No, but speculation makes any conclusion you want to draw possible. If you want to argue that Microsoft will come out and implement PGP, that's one thing. Hell, maybe Google will decide that it's more profitable to shut down Gmail. Would that also be a mistake from a strategic point of view? I couldn't fault them for it. But all you have are wishes and fantasies. That's not strategy. That's a pipe dream.
- shkkmo 12y ago
  That would make sense anyway from a UI perspective. The 'encrypt this email' option can clearly only work if google is able to reliably determine (or have you provide) the correct public key for the address or person that you are emailing.
zmanian 12y ago
In the current state of affairs, lawful intercept/ PRISM devices on Google's network can potentially see everything behind the SSL layer. The global passive attacker can see all incoming and outgoing emails between providers that don't use StartTLS. Google needs to provide the email history < 6 months of US person in response to a administrative subpoena and >6 months with a warrant. Let say Google made a key directory and end 2 end encryption possible in Gmail but Google held the keys. This would frustrate blanket lawful intercept and the global passive attacker. Google might be able to legally argue that turning over keys requires a proper warrant. They might be able to defend against falsifying the key directory because of external audits.This is roughly where Apple is with iMessage. If Google goes a step further and only stores an encrypted key or keeps the key client side, now we have the legal terrain of the Government asking a software provider to maliciously modify their software to obtain keys or a passphrase. I think this legal battle is coming. We might be able to preempt it with software verification techniques but definitely coming down the pipe.
- Zigurd 12y ago
  IANAL but I did write a "lawful intercept" (LI) spec for a type of infrastructure router. As far as I know, most places in what we'd call "the free world" don't compel carriers to do anything to thwart users from protecting their payloads, nor do they compel carriers to actively deny service to encrypted payloads or even discourage use of encryption. Even if individuals can be compelled to hand over keys, it isn't the carriers' problem. Empirically, we know that, for about a year, Google, Yahoo, etc. have been bitching about PRISM, but not doing anything to make it more convenient for their customers to encrypt their payloads. Is there some secret law? Heavy-handed pressure? Or did they just spend a lot of time wishing the privacy thing would just go away? This will be an interesting test to see just how much freedom Our Benevolent Overlords think we can handle.
- panarky 12y ago
  > PRISM devices on Google's network can potentially see everything behind the SSL layer Is there evidence of this, or is this your assumption? I'm aware that NSA monitored unencrypted data transfers between data centers on Google's dedicated fiber circuits, but as far as I know that was accomplished through telcos and not Google. Google said they've now encrypted the circuits between data centers, and they've strenuously denied allowing monitoring devices to reside on their network. Is there another exploit I'm not aware of?
oakwhiz 12y ago
Issue #2 could potentially be solved by a homomorphic cryptosystem in the future.
tvladeck 12y ago
> 2. "Also, Google wouldn’t be able to scan and index the text of your e-mails. That’s a problem if you need to search for old emails not stored on your own machine. It could be a real issue for Google’s business model as well, which involves scanning the text of emails in order to place contextual advertising." Caveat: I am no expert whatsoever in crypto/CS so understand this is almost certainly non-workable for some reason (which is what I'm trying to understand). Why couldn't Google hash every word in an email and store the list of hashes alongside the encrypted version. Then when you search for something, the search terms are hashed as well and the service searches for the hashed search terms amongst the lists of hashes. Edit: Thanks everyone!
- level 12y ago
  Because that's not really making it private. If you have each word hashed and a rainbow table full of hashes matched to words, it's very easily reversible. It doesn't really introduce any privacy. Not to mention the computational and storage cost.
  - ithkuil 12y ago
    would a per user salt help with the rainbow table issue?
    - mike-cardwell 12y ago
      No. With a list of the users hashes and their salt, you could reverse it all in a matter of minutes or seconds on even a single low spec machine. It would offer nothing over just storing the plain text.
      - ithkuil 12y ago
        are you sure? I can think of weaknesses caused by statistical properties of a large corpus of hashed terms (all with the same salt) clustered together in documents which follow a natural language distribution, but matter of minutes or seconds? Why doesn't that simplicity apply for salted hashed passwords?
mike-cardwell 12y ago
> Who stores my private key? Google? Chrome? Both seem troublesome If you use the OpenPGP plugin for Roundcube, you paste your key into a form on the settings page whilst logged in, and it gets stored in your browsers localStorage (never sent to the server). Of course, with this system, the key needs to be managed externally and pasted into each browser you use, and you need to trust that the server doesn't send modified JS which steals your key. To make it so you don't have to manage the keypair externally, it could be sent to the server after being encrypted using a password, then whenever you need to use a new browser, it will retrieve the encrypted key from the server, decrypt it with your supplied password and then store it in localStorage. Or perhaps it should remain encrypted when in localStorage, and when you log in, retrieved from localStorage, decrypted with a supplied password and then stored in a global variable. Javascript crypto in the browser works... until the person running the server decides to steal your key when you log in, or until somebody finds an XSS flaw in the app.
- deleted 12y ago
  [deleted]
- Lx1oG-AWb6h_ZG0 12y ago
  Why can't the browser do the crypto on your input, before it even gets to the site/js? (e.g., expose a secure input and output API (say, a new type of HTML textarea and markup tag). Whenever you start entering text, or when a secure element enters the viewport, look up the key for the site (stored locally, like how they remember passwords) and encrypt/decrypt the content. All the site/js sees is gibberish.
  - rcxdude 12y ago
    You will also need a mechanism for marking the input as secure which can't be duplicated by a malicious webpage.
  - mike-cardwell 12y ago
    It could. But it hasn't been done yet. And as rcxdude stated, it would need to be done in such a way that you can't create a fake secure textarea using HTML. Perhaps when focusing on one, all other script on the page stops, no events or timeouts are triggered, everything other than the secure textarea is ghosted out, and something big and obvious in the browsers chrome lights up to show you that you are actually focused on a "secure textarea" and not a normal one.
freehunter 12y ago
IIRC, Google doesn't mine information from paid-for accounts, so this encryption could be a feature for accounts where the user is paying Google for the service. That's a pretty small number of accounts though, I would think.
- lttlrck 12y ago
  what about searching?
  - zmanian 12y ago
    Also priority inbox and antispam.

Thirdegree 12y ago

In response to 2) I would say the best way (from Google's perspective) would be a way to flip a switch on a per-email basis. So by default, emails aren't secure, but if you need it you can activate it. I wonder if the loss of data would be worth the increase in users though.

higherpurpose 12y ago
> I wonder if the loss of data would be worth the increase in users though. I think that's the wrong way for Google to look at it. The question should be "how many users will I lose if I don't enable something like this in my services soon?" The best thing American companies could do right now, especially large ones like Google, to make sure regions like Latina America or Europe don't take a "you have to build your datacenter here" stance and make things much more expensive for them, is to ensure that the data is private, even if it's on American servers, because they've adopted trustless protocols, and even they can't see what's inside. That's what's going to stop users and institutions from other countries from bailing on American corporations like Google. So losing a little data signal from the ad tracking data is hardly a big loss in comparison, and could help Google regain at least some of the trust they lost post-NSA revelations.
- saraid216 12y ago
  > I think that's the wrong way for Google to look at it. The question should be "how many users will I lose if I don't enable something like this in my services soon?" Since this answer is "an insignificant amount", I think you'd be happier if Google looked at it the wrong way.
  - higherpurpose 12y ago
    Insignificant only when you look at the way things work right now. This is the problem with monopolies such as Comcast, too. They think "hey why bother improving the service, and cost us money, when we're not going to lose customers to anyone anyway"? That only works when there's no competition or the competition isn't serious enough. But as soon as something like Google Fiber comes out, they start freaking out, because they know customers have developed a lot of resentment towards them when they kept thinking "why bother improving the service?", and they will quit them as soon as a much better alternative is available. The same can happen to Google, too. Imagine if this was Microsoft coming out today and saying they are going to implement PGP or something even better for true privacy - and imagine then they would do campaigns like Scroogled and Gmail Man. Now do you still think it's a mistake for Google to do this from a strategic point of view, so they don't lose customers in the future? If Google wants Gmail to remain the #1 e-mail service, then they need to do such moves first, not as a reaction to other competitors. Because by then the exodus may be too hard to reverse, if the perception of Google's services becomes much poorer and they've lost most users' loyalty (not necessarily the users themselves up to that point - but the loyalty of those users).
    - saraid216 12y ago
      No, but speculation makes any conclusion you want to draw possible. If you want to argue that Microsoft will come out and implement PGP, that's one thing. Hell, maybe Google will decide that it's more profitable to shut down Gmail. Would that also be a mistake from a strategic point of view? I couldn't fault them for it. But all you have are wishes and fantasies. That's not strategy. That's a pipe dream.
shkkmo 12y ago
That would make sense anyway from a UI perspective. The 'encrypt this email' option can clearly only work if google is able to reliably determine (or have you provide) the correct public key for the address or person that you are emailing.

zmanian 12y ago

In the current state of affairs, lawful intercept/ PRISM devices on Google's network can potentially see everything behind the SSL layer. The global passive attacker can see all incoming and outgoing emails between providers that don't use StartTLS. Google needs to provide the email history < 6 months of US person in response to a administrative subpoena and >6 months with a warrant. Let say Google made a key directory and end 2 end encryption possible in Gmail but Google held the keys. This would frustrate blanket lawful intercept and the global passive attacker. Google might be able to legally argue that turning over keys requires a proper warrant. They might be able to defend against falsifying the key directory because of external audits.This is roughly where Apple is with iMessage. If Google goes a step further and only stores an encrypted key or keeps the key client side, now we have the legal terrain of the Government asking a software provider to maliciously modify their software to obtain keys or a passphrase. I think this legal battle is coming. We might be able to preempt it with software verification techniques but definitely coming down the pipe.

Zigurd 12y ago
IANAL but I did write a "lawful intercept" (LI) spec for a type of infrastructure router. As far as I know, most places in what we'd call "the free world" don't compel carriers to do anything to thwart users from protecting their payloads, nor do they compel carriers to actively deny service to encrypted payloads or even discourage use of encryption. Even if individuals can be compelled to hand over keys, it isn't the carriers' problem. Empirically, we know that, for about a year, Google, Yahoo, etc. have been bitching about PRISM, but not doing anything to make it more convenient for their customers to encrypt their payloads. Is there some secret law? Heavy-handed pressure? Or did they just spend a lot of time wishing the privacy thing would just go away? This will be an interesting test to see just how much freedom Our Benevolent Overlords think we can handle.
panarky 12y ago
> PRISM devices on Google's network can potentially see everything behind the SSL layer Is there evidence of this, or is this your assumption? I'm aware that NSA monitored unencrypted data transfers between data centers on Google's dedicated fiber circuits, but as far as I know that was accomplished through telcos and not Google. Google said they've now encrypted the circuits between data centers, and they've strenuously denied allowing monitoring devices to reside on their network. Is there another exploit I'm not aware of?

oakwhiz 12y ago

Issue #2 could potentially be solved by a homomorphic cryptosystem in the future.

tvladeck 12y ago

> 2. "Also, Google wouldn’t be able to scan and index the text of your e-mails. That’s a problem if you need to search for old emails not stored on your own machine. It could be a real issue for Google’s business model as well, which involves scanning the text of emails in order to place contextual advertising." Caveat: I am no expert whatsoever in crypto/CS so understand this is almost certainly non-workable for some reason (which is what I'm trying to understand). Why couldn't Google hash every word in an email and store the list of hashes alongside the encrypted version. Then when you search for something, the search terms are hashed as well and the service searches for the hashed search terms amongst the lists of hashes. Edit: Thanks everyone!

level 12y ago
Because that's not really making it private. If you have each word hashed and a rainbow table full of hashes matched to words, it's very easily reversible. It doesn't really introduce any privacy. Not to mention the computational and storage cost.
- ithkuil 12y ago
  would a per user salt help with the rainbow table issue?
  - mike-cardwell 12y ago
    No. With a list of the users hashes and their salt, you could reverse it all in a matter of minutes or seconds on even a single low spec machine. It would offer nothing over just storing the plain text.
    - ithkuil 12y ago
      are you sure? I can think of weaknesses caused by statistical properties of a large corpus of hashed terms (all with the same salt) clustered together in documents which follow a natural language distribution, but matter of minutes or seconds? Why doesn't that simplicity apply for salted hashed passwords?

mike-cardwell 12y ago

> Who stores my private key? Google? Chrome? Both seem troublesome If you use the OpenPGP plugin for Roundcube, you paste your key into a form on the settings page whilst logged in, and it gets stored in your browsers localStorage (never sent to the server). Of course, with this system, the key needs to be managed externally and pasted into each browser you use, and you need to trust that the server doesn't send modified JS which steals your key. To make it so you don't have to manage the keypair externally, it could be sent to the server after being encrypted using a password, then whenever you need to use a new browser, it will retrieve the encrypted key from the server, decrypt it with your supplied password and then store it in localStorage. Or perhaps it should remain encrypted when in localStorage, and when you log in, retrieved from localStorage, decrypted with a supplied password and then stored in a global variable. Javascript crypto in the browser works... until the person running the server decides to steal your key when you log in, or until somebody finds an XSS flaw in the app.

deleted 12y ago
[deleted]
Lx1oG-AWb6h_ZG0 12y ago
Why can't the browser do the crypto on your input, before it even gets to the site/js? (e.g., expose a secure input and output API (say, a new type of HTML textarea and markup tag). Whenever you start entering text, or when a secure element enters the viewport, look up the key for the site (stored locally, like how they remember passwords) and encrypt/decrypt the content. All the site/js sees is gibberish.
- rcxdude 12y ago
  You will also need a mechanism for marking the input as secure which can't be duplicated by a malicious webpage.
- mike-cardwell 12y ago
  It could. But it hasn't been done yet. And as rcxdude stated, it would need to be done in such a way that you can't create a fake secure textarea using HTML. Perhaps when focusing on one, all other script on the page stops, no events or timeouts are triggered, everything other than the secure textarea is ghosted out, and something big and obvious in the browsers chrome lights up to show you that you are actually focused on a "secure textarea" and not a normal one.

freehunter 12y ago

IIRC, Google doesn't mine information from paid-for accounts, so this encryption could be a feature for accounts where the user is paying Google for the service. That's a pretty small number of accounts though, I would think.

lttlrck 12y ago
what about searching?
- zmanian 12y ago
  Also priority inbox and antispam.