Posted by Ken Kantzer on 16 November 2015
It seems that every week, "yet another" end-to-end encrypted app is unleashed on the world. I've been looking for an reason to use D3, so I combined data from the EFF's Secure Messaging Scorecard with some very rough user numbers I was able to find (radius corresponds to user base):
Look at all those apps in the top right. True, most of them have relatively small user bases compared to the heavy-hitters in the bottom half of the graph, but iMessage and Facetime are end-to-end, and have giant user bases. If Tim Cook thinks users care about privacy, and Apple is differentiating itself on this axis, then it's probably "a thing."
In this post, I'm going to be looking at why the slew of "yet another" end-to-end apps might fuel a shift in incentives for some cloud services, away from the prevalent "data-as-value" model, towards a "data-as-liability" model.
This is because end-to-end encryption is turning out to be a good solution for mitigating some of the concerns about the cloud's security model. If these incentives end up aligning in a way that benefits privacy, and there’s no guarantee that they will, this would mean great things for us as the end-users.
Before we begin, let me make something abundantly clear. This post is not trying to argue that client-side encryption is right for every cloud service out there. Most companies that operate online need to access their user's data in order to provide them useful services, making end-to-end encryption the last thing they'd want to do. If I'm a social media company designed to let my users communicate with the public, it stands to reason that I might want that data to be publicly accessible.
So why is it a good thing that all these end-to-end encrypted apps are popping up? Well, it means that privacy has started to enter the public conscience, and more privacy is always good. But I'd like to focus on a more subtle reason why end-to-end might become more prevalent: it can help companies solve some of the data security issues that come with being in the cloud.
As data is being exchanged across the cloud, particularly with microservices and distributed databases like Cassandra, the ability to render that data inert by just deleting a key is pretty incredible.
Cloud services face the same security problem that banks have always faced as highly concentrated aggregators of wealth. As this wealth accumulates, banks render themselves extremely attractive targets for criminals.
Banks are of course aware of this, and they have a slew of security measures in place to protect themselves, like dye packs, silent alarms, and marked bills.
But cloud services have it much, much worse than physical banks, thanks to a giant surface area that grows with each new feature the cloud service rolls out. A wall is pretty much a wall. Code is...different. It has properties that make it hard to secure.
To make matters worse, anything on the Internet is infinitely more susceptible to attack. As a physical analogy, imagine if banks had to deal with robots that could travel at the speed of light, were remote-controlled, and had automatic safe cracking tools. Cloud services face this scenario every day. As soon as a service exposes itself to its market segment on the internet, it exposes itself to everything on the Internet.
Bruce Schneier has started referring to the data we store online as the pollution problem of the information age. The Internet's growth has been fueled on turning user data into money.
But what if data isn't perceived as a revenue source? What if it instead becomes a liability, either because users demand stronger privacy, or because your user's data represents a giant money-sucking security issue, as it does for banks?
For services that perceive their user's data is a liability, client-side encryption starts making a whole lot of sense. We have a nexus of incentives:
Services don't want their security issues to scale with the value of data their users put into their system.
Customers don't want to become collateral damage to an epic hack. Their risk is by no means gone, but at least it isn't tied to the security of every other user on the service.
End-to-end encryption allows services to decentralize data. It allows users to have stronger guarantees about what it means to delete their data, since access control is mandated by the encryption, rather than the weaker guarantees that service providers typically offer. Encryption allows services to delete encrypted data in a infrastructure-agnostic way: if you delete the key, you've effectively deleted the data.
Guarantees which are often wrong, by the way. When was the last time you checked whether your service provider deletes logs across its services?
So far, discussions about end-to-end encryption have primarily risen as a response to a perverse cloud model where services are incentivized to collect as much data as possible. But times are a'changin, and other incentive models are starting to surface. For companies like our own that hold a lot of customer data that they don't need to access, it's reasonable to start thinking of client-side encryption as a way to lower their own exposure. Only time will tell if this ever becomes truly cost-effective for mainstream cloud services.
End-to-end encrypting a service is not a cake-walk. Issues like search are still hard, and are active areas of research, but even so, it might be worth the blood, sweat, and tears involved. If this means more privacy and security for the end-user, then that's a very good thing.