
A plea to Google: Protect our e-mail privacy - iProject
http://arstechnica.com/tech-policy/2012/12/op-ed-a-plea-to-google-protect-our-e-mail-privacy/
======
jmillikin
(disclaimer: I'm employed by Google, though not in anything related to Gmail)

The article quotes Vint Cerf as saying that encryption isn't being used
because it would inhibit advertising, but I think that's incorrect. There is
no obvious reason why ads couldn't be selected client-side, with the text of a
message sent to Google over an encrypted connection and not stored.

In my opinion, there are at least three much more significant reasons why
Gmail won't support end-to-end encryption:

1) It puts a huge barrier in front of new users. Instead of picking a username
and password, now they have to create an encryption key, have a (strong!)
password for the key, install client-side software to manage it, keep a backup
of the key, and keep backups of their email in an encrypted form (with yet
another strong password).

Can you imagine any ordinary person going through with all that just to read
email?

\--

2) User-managed encryption would be a support nightmare. Imagine: your
grandmother buys a new laptop, and donates her old beige box to a local
school. After getting home, she tries to check her email. Except she can't,
because the encryption keys were on her old computer, and now they're just
noise on some platters because the school's IT guy wiped the drive.

Would you want to be the customer support agent who had to tell her that her
email was gone forever, and that she would have to make a new account with a
new address?

This is why no major company encourages users to manage their own encryption
keys, and why every company that does will never become a major company.

\--

3) Google's primary value-add to anything is search. That's their brand, they
are the company people go to for finding stuff. End-to-end encryption means
that Gmail can't do search any more, and then what's the point of even having
Gmail? Even if you could somehow convince users that it's worth putting up
with all the extra hassle to protect their email, you'll never convince a
company that it should scrap one of its most successful products just because
a fraction of a percent of its userbase thinks its existing security features
are insufficient.

\------------------------

Here's another thought. The world the author describes, where people install
special client software to manage their keys and read their email, ALREADY
EXISTS. If people actually want to, they can download Thunderbird and GPG and
set up their keys and treat Gmail as just another IMAP/SMTP service. It's an
annoying process, but the only ways to make it simpler would also render it
useless by reducing the security.

So really the author isn't asking for Gmail to support encrypted email, _he's
asking Gmail to stop supporting un-encrypted email_. Hands up if you think
this will ever happen.

The fact that nobody outside the crypto-nerd community uses existing client-
side encryption support is strong evidence that most users consider the
convenience of provider-readable mail to be more important than protection
against police warrants.

~~~
napoleond
You're right, there are very real barriers to this happening, and I agree that
the author of the article may not have considered them all, but barriers
aren't always insurmountable.

(1) basically reduces to having the user install client software (which would
handle key management, etc). Not easy (and complicated by the fact that
existing software sucks) but not impossible.

(2) is probably the biggest challenge. The solution requires a server which
can manage keys without being able to read them. It does reduce the strength
of the system to a strong passphrase or series of passphrases (and there are
ways of making the UX for this less horrible than it currently is in most
places) but that's still way better than anything we have right now--it
essentially reduces the attack vectors available to someone with _root access
to the server_ to those available to everyone on the internet for any other
service right now (ie. brute force).

(3) I agree, no one will ever convince Google to encrypt Gmail. Search would
still work for meta information though (to/from/subject lines) which is good
enough for most situations. The client would be able to perform deeper
searches within a particular date range by decrypting messages in that range
should it be necessary.

So yeah, the world of encrypted email already exists but it sucks. Yes, making
it easier involves reducing security somewhat (not even close to "rendering it
useless") but it also provides a level of privacy that should have been
expected from the get-go. _Nobody should be able to run a search on every word
I've written to anyone in the past ten years but me._ The fact that nobody
outside the crypto-nerd community uses existing client-side encryption has
more to do with the poor usability of existing solutions and general
(changing) assumptions about the privacy of email than anything to do with
police warrants.

~~~
jmillikin
For (1), if the user has to install software on their client, then the entire
point of webmail has been bypassed.

I disagree that reducing the security wouldn't render end-to-end encryption
useless. Remember that the purpose of end-to-end encryption is to protect the
user against malicious service providers. If you want to store a user's data
on a Google server, but ensure that Google is unable to read it for XX years,
then you need to take a lot of security precautions. Forgetting any of them
would allow the user's data to be compromised.

    
    
      > Nobody should be able to run a search on every word
      > I've written to anyone in the past ten years but me.
    

If this is your goal, then your only realistic option is to install an open-
source mail client on its own dedicated machine, set up GPG, generate your GPG
keys on that machine, and don't let it do anything but talk SMTP+POP3 with
your mail provider. Read all your email in plaintext.

This sounds paranoid, but it's actually the absolute minimum required if you
want to ensure that your emails are safe from a malicious entity with
corporate- or government-sized budgets. Further precautions might include
removing the HDD and keeping the machine airgapped with email transfer
performed by CD-ROM. Then you get to go down the physical-security rabbit hole
to prevent someone with a warrant from bugging your keyboard.

The reason for all these precautions is that a malicious provider could save
all of the encrypted emails you send/receive over the years. They only need to
grab your keys once.

Or you could, you know, relax a bit and figure that storing personal email on
Google/Microsoft/Yahoo/Apple servers is probably OK.

~~~
napoleond
It's not webmail as we know it, that much is true. In an age of mobile and
tablet prevalence, that's less important than it used to be. It would still be
possible to _send_ emails from a browser session (doesn't require exchanging
private keys, it just wouldn't be signed... in other words, a "stopgap" sort
of ability) and if you are using a trusted SSL connection (I know that's an
_if_ , but still pointing it out) you could have synchronous communications in
a browser that were still being saved in an encrypted format.

The purpose of this is actually _not_ to prevent a concerted attack on your
communications--there are too many physical/social vectors in that scenario
for encryption to even matter. The purpose is to prevent your personal
correspondence from being indexed anywhere outside of your complete control,
and to be transmitted in a way that prevents the elementary eavesdropping
possible today. It should also make the sort of subpoena requests performed by
"regular" law enforcement impossible. Most departments don't have the
resources to crack a sufficiently complicated passphrase. So what I should
have said is _nobody should be able to run a search on every word hundreds of
millions of people have written in the past ten years which they thought was
private correspondence_. And the system I am describing really would put an
end to that ability. (NOTE: I'm _not_ saying I think anyone at Google can do
that. Maybe the NSA, but there's no proof of that either. My only point is
that it's very technologically feasible right now and it shouldn't be.)

EDIT: By the way, for people who _do_ know what they're doing and _are_
willing to go through the extra steps, a system like the one I describe here
(and am building) is still a net win--instead of your ultra-secure setup being
limited to communicating with your ultra-secure friends, there would be a
middle road for general communications with less tech-savvy associates.

~~~
jmillikin

      > nobody should be able to run a search on every word
      > hundreds of millions of people have written in the past
      > ten years which they thought was private correspondence.
    

If it's possible for your provider to compromise your system and take your
keys, then they can run a search on everything you've sent through their
routers.

If they can compromise one system, they can automate it and compromise ~100%
of typical consumer machines, and then have access to all of their email.

The steps I described do not stop a concerted attack. They are merely the
minimum required to prevent blanket surveillance of all email accounts managed
by any given provider. If someone does less than what I described (and I'm
sure I didn't get everything), then sending encrypted email is just wasting
their own time.

~~~
napoleond
Forgive me, but I don't understand how what you're describing is remotely
possible. Cracking a single bcrypted passphrase should take an average time on
the order of _years_. NSA and their ilk can maybe reduce that significantly,
but they still won't be cracking an entire system any time soon, even if it's
only 1,000 user accounts.

We must be talking past each other. I promise I'm not trying to be obtuse--
could you please try again?

~~~
jmillikin
A malicious provider wouldn't have to brute-force the key; they could
compromise your browser to steal the key and install a keylogger to take your
password. Browser exploits aren't expensive, and zero-days are discovered
semi-regularly.

A sufficiently well-capitalized provider could even pay researchers to find
new browser exploits, so they don't have to depend on scavenging them out of
feral malware samples.

This would probably work only once or twice, but would give that provider the
ability to read any encrypted payloads that they have recorded.

~~~
napoleond
Ahh yes, we did somehow manage to misunderstand each other completely. There
is no scenario in my system in which the browser sees any keys or passphrases,
encrypted or otherwise--that would only happen in a signed standalone client
program capable of running native code. (The browser _does_ see a password in
the potential "send-only" scenario I described earlier, but that's a separate
secret unrelated to the PGP key.) Yes, it would be possible to maliciously
alter that code and redistribute it, but it would be difficult since the
source would be open and anyone could verify the hash. At that point, it's
probably easier to just infect the host computer with a keylogger some other
way (and wait for the user to lose their key so that they need to use their
passphrase, then intercept 2 factor auth somehow), but that's like the _deus
ex machina_ of computer security (and still not at all automatable at large
scale as far as I can see, especially due to 2FA).

~~~
jmillikin
If the user's browser runs in the same account as the user's mail client, then
any browser exploit will be able to access the user's key.

The keylogger would be to take the user's key password. To my knowledge, there
is no way to hook up 2FA for accessing a GPG(,etc) key.

~~~
napoleond
I think you're making some assumptions which don't apply to the system I'm
working on. We're getting pretty far to the right margin in this thread, but I
would love to continue this discussion out of band (and it's entirely possible
that I really have missed something, in which case I would like to know it
sooner rather than later). My email is in my profile :)

------
napoleond
My little company has started working on a solution to this:
<http://parley.co>

Google will never store email in a properly encrypted fashion, because their
incentives lie with advertisers rather than with users. The only way for
encrypted email to both work and reach mass appeal is for it to be implemented
in such a way that private keys never touch the server while still being
ridiculously simple to use at a highly accessible price point.

~~~
duaneb
> Google will never store email in a properly encrypted fashion, because their
> incentives lie with advertisers rather than with users.

Also I'm pretty sure search would suck with encryption, which is easily the
primary draw of GMail for many people.

~~~
napoleond
I agree that search is pretty nice to have, but most of the time I find myself
searching for "messages from so-and-so" or "that email I wrote about X" which
is still searchable after encryption (subject fields remain unencrypted, and
you obviously also have to/from/date/time). For deeper searches, a client
could decrypt and search a smaller time span (messages to X last week
containing Y).

It's still a trade-off, but I don't think it's a deal-breaker at all. I also
think we overestimate how much non-geeks know about search features in GMail.

~~~
thezilch
Why are those fields still searchable after encryption? Doesn't that fly in
the face of the article's utopian state of email? I can still see you're
emailing with this contact, at this frequency, and with these subjects; seems
like an awful lot of insecure leakage.

~~~
napoleond
PGP doesn't encrypt the recipient's address for obvious reasons. Subject and
sender are useful for the recipient; it's a tradeoff, as all security is.

------
graue
Someone needs to invent a Firefox or Chrome addon that solves this problem.

Here's how I see it working. You get a message on Gmail, and it looks like
this:

    
    
        This message is encrypted with FooAddon.
        To view it, copy and paste the encrypted message
        to a FooAddon tab.
        
        ----FOOADDON MESSAGE START
        ...a bunch of base64-encoded binary data...
        ----FOOADDON MESSAGE END
    

You paste that into the addon's tab and it uses your private key to decrypt
and show the message.

To send, you select the recipient's public key in a FooAddon tab and type your
message there, then click Encrypt. It gives you something like the above which
you then copy and paste back into Gmail.

Clumsy, yes, but you'd have a working proof-of-concept that would allow you to
send and receive encrypted messages through _any website with a text field_
without leaving the browser.

The security implications of being able to type a secure message directly in
Gmail and be sure Google isn't reading it with JavaScript are no doubt much
more complicated.

~~~
jmillikin
<http://www.mozilla.org/en-US/thunderbird/>

<https://addons.mozilla.org/en-us/thunderbird/addon/enigmail/>

~~~
graue
Since you missed it, the key point of my proposal was that it works:

> through any website with a text field

> without leaving the browser

~~~
jmillikin
I don't consider either of those to be useful, because once you've had to open
a new window/tab, you might as well just have opened another application.

This recent obsession with rewriting the world to run in a jumped-up document
rendering system is unhealthy and insane.

~~~
graue
It's a question of adoption. Asking people to install a browser addon is
easier and less hassle than a whole new application.

I use Thunderbird myself, but if we want email encryption available to
everyone - not just us geeks - then the simpler we can make it, the better.

------
jackpirate
GMail will probably never encrypt our emails for us. But what it could do is
automatically decrypt someone else's email and verify the signature. This
would make encryption much more accessible without any (advertising) cost to
Google.

~~~
jmillikin
Automatic decryption would require uploading a copy of the recipient's private
key to Gmail, which rather defeats the purpose of end-to-end encryption.

For protecting mail in transit, SMTP TLS is just as secure and much easier to
deploy.

~~~
AnthonyMouse
SMTP TLS has to be deployed by the email server admin. Google could implement
PGP (with the private key stored on their server) and it would work with any
PGP-compatible email client regardless of support by the peer's email
_server_. So for example, if your company runs your email server and doesn't
use SMTP TLS, you can still use e.g. Thunderbird with GPG and correspond with
someone who uses gmail without the gmail user having to take any steps
whatsoever -- it would be trivial for google to supply a page like
'<https://gmail.com/[username@gmail.com]/PGP> (and autogenerate a new key for
any guessed address to thwart spammers guessing addresses), where you could
get a copy of the user's public key and then send encrypted messages without
the gmail user having to do a single thing.

That doesn't keep the email private from Google, but if your only concern is
to keep your communications private from your email provider for some reason
(or from your ISP etc. if you like your email provider other than the fact
that they don't use SMTP TLS), it gives you something you didn't have before.

~~~
jmillikin
"That doesn't keep the email private from Google, but if your only concern is
to keep your communications private from your email provider"

If you use Gmail, then Google is your email provider.

~~~
AnthonyMouse
And if you don't use Gmail, but you're corresponding with someone who does,
then Gmail is not your email provider.

------
woodchuck64
Don't quite understand why Google drafts would be thought safer than Google
email (between Google addresses). Aren't both sent via (technically unsafe)
https and stored on some google disk somewhere?

~~~
pavel_lishin
If I send you an e-mail, it exists in at least two places on Google's servers,
and on whatever devices you've used to read and send the message.

~~~
woodchuck64
I agree that it exists on two places on Google's servers, but a draft also
exists on every device that has used that account (and viewed or edited the
draft).

