Over the weekend, I had a piece at Ars Technica urging Google to roll out end-to-end encryption for Gmail, allowing hundreds of millions of ordinary users to enjoy the level of privacy now largely reserved for paranoid ubergeeks. I tried to address some of the obvious economic reasons Google might be hesitant to do this, but as Princeton’s Ed Felten points out, there are important technical questions as well:

First, how would the crypto keys and crypto code be managed? […] To start with, we would need a place to store your private key. We could store it on your desktop, but this would conflict with the usual cloud model that gives you access from multiple devices. We could have Google store your private key for you, then download it to whatever device you’re using at the moment, but then what’s the point of encrypting your messages against Google? The best solution is to have Google store your private key, but encrypt your private key using a password that only you know. Then Google would download your encrypted private key to your device, you would enter your password, and the private key would be decrypted on the device.

This is pretty much how I’d imagined it working for the average user, but there’s no real reason we need a one-size-fits-all solution here; lots of cloud services that offer encryption let the user choose whether or not to let the provider keep a backup copy of the user’s keys. The more paranoid could sacrifice some mobility and convenience—and risk losing access to some of their messages if their local copies of the key are destroyed—by opting not to let Google keep even an encrypted copy of their key. Or, as a middle ground, a user could always store an encrypted backup copy of her key with a different cloud provider, like Dropbox, which need not even be known to Google. That provides all of the advantages of storing the key with Google at a relatively minor cost in added hassle, but substantially raises costs for any attacker, who now must not only crack the passphrase protecting the key, but figure out where in the cloud that key is located. Assuming it’s accessed relatively infrequently (most of us read our e-mail on the same handful of devices most of the time) even a governmental attacker with subpoena power and access to IP logs is likely to be stymied, especially if the user is also employing traffic-masking tools like Tor

The next problem we would have to solve is how to do cryptography in the browser. A service like GMail has to run on lots of different devices with differently abled browsers. Presumably the cryptographic operations–including time-consuming public-key crypto operations–would have to be done in the browser, using the browser’s Javascript engine, which will be slow. It would be nice if there were a standardized API for in-browser crypto, but that doesn’t exist yet, and even when it does exist it will take a long time to be deployed so widely that a public service like GMail can rely in it being present on all devices.

What is most problematic is that the software code to do all of this–to manage your keys, decrypt messages, and so on–would itself be written and delivered by Google, which means that Google would, after all, have the ability to see your messages, simply by sending you code that silently uploaded your keys and/or data. So if your goal is to make it impossible for Google to see your messages, for the protection of you and/or Google, then you won’t have achieved that goal. […] The only solution we know is to acquire the secure functionality by a traditional download, incorporating carefully vetted code that cannot be modified or updated without user control. The code might be provided as a standalone app, or as a browser extension. We could do that for GMail (and at least one company has done it), but that would give up some of the portability that makes the cloud email attractive.

I think the speed issue is probably not that big a deal on newish devices, and will only become less of an issue, but for some of the other reasons Ed cites, the preferable way to do this is with dedicated client software. This does create some sacrifice in terms of portability, but frankly if you’re really concerned about secure communications you probably don’t want to be decrypting your sensitive messages on untrusted devices anyway. Also, as I note in the piece, this is where Google has an advantage as the distributor of a widely-used open source operating system and browser. The relevant functionality could come bundled with Chrome and/or Android (and serve as a selling point for both) as well as being offered as a separate plugin for other browsers (or bundled with Google’s widely-installed voice/video chat plugin). Users could still, of course, access their unencrypted webmail from any old browser, but one imagines that if Google leads the way, other developers will have a strong incentive to make their own software compatible.

The second major issue is how to keep messages secret while still providing GMail features that rely on Google seeing your messages. These features include spam filtering (which you couldn’t live without) and the content-based ads that Google shows next to your messages (which Google probably wouldn’t want to live without). Can these be provided without leaking the full content of messages to Google? I suspect the answer is a qualified yes–that pretty good versions of these features could be provided in a more privacy-friendly way–but that’s a topic for another day.

Add to these issues that encrypted messages won’t be searchable (unless stored locally as plaintext), which is a bit of an inconvenience, but probably not a dealbreaker. You can probably still do a good deal of spam filtering just using metadata, and it helps that most users will generally be trading encrypted messages with friends and contacts. Users might even elect to only get such messages from “buddies,” whitelisted addresses, or (more permissively) other Gmail users, which would make encrypted e-mail within the service a little bit more akin to Facebook or Gchat messaging. At least initially, it probably makes sense to have this be the default, and users who really need to get encrypted messages from random, unapproved senders they’ve never interacted with before can tweak their settings to let those messages through.

As for content ads, well, that’s the million dollar question—and as Vint Cerf has candidly acknowledged, a primary reason Google hasn’t already done this. My answer here is the same as it was in the article: First, most people are still going to exchange a lot of unencrypted messages, and Google can still serve keyword ads based on those. Second, Google recently revised its policies to allow sharing of user information between its disparate services, provoking some grumbles from privacy folks. That means they’ve got a hell of a lot of other data to draw on in determining what ads are likely to be relevant to a particular e-mail user, from search history to favorite YouTubes, which I’d actually expect to be substantially more useful for tailoring ads than e-mail keywords. Also, at least initially, using the encryption feature will probably mean logging directly into your Google account via their Web interface (where Google gets to show you ads) rather than simply reading your messages in an ordinary mail client (where they don’t). So the loss of one kind of targeting data from some messages has to be balanced against the probable increase in ad exposures. It’s up to Google’s accountants to figure out how that all nets out, but these considerations seem like a good prima facie reason to at least run the numbers if they haven’t done it recently.