Last week Julian Sanchez urged Google to offer end-to-end encryption for GMail, so that your messages would be known to you and your browser (and your email correspondents) but not to Google itself. Julian explained why this would be a positive step for users and, arguably, for Google itself. Let’s talk about what would be required to make it happen.
We have had standards for end-to-end email encryption for a long time: PGP since at least 1996 and S/MIME since at least 2002. In these systems, each user has a private key that they use to encrypt and digitally sign their email. If two people know each other’s public keys, they can exchange email securely without the network, or even their email services, being able to read or tamper with the messages. This feature has long been supported in desktop email clients. What would we need to make it work for a cloud email service like GMail?
(I’m using GMail as an example here, not to pick on Google but because that’s the example Julian used. Other cloud email services would face the same challenges.)
There are two issues, which we’ll deal with one at a time. First, how would the crypto keys and crypto code be managed? Second, what about the features of GMail that rely on Google seeing your messages?
First, managing keys and code. 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.
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.
This problem–the inability to provide end-to-end encryption in a webapp, because the code can be modified by the app provider–has been the downfall of many a “brilliant” security idea over the years. 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.
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.
Leave a Reply