[tech] Why You Don't Have End-to-End Encryption
Sit down. We need to talk.
In regards to the previous post (Re firesheep), you might reasonably ask, "What the hell? If by Web 2.0 sites using this here 'encryption' stuff they would protect our accounts, why aren't they doing that? What's the hold up?"
There are several hold ups. And one of them is you.
Implementing encryption solutions has some serious technical challenges, but one of the worst problems is social.
I speak as a web developer. I live in this world, professionally, and have done for a decade. And I am here to tell you, one of the things sapping the will of website owners to do what is necessary for end-to-end encryption has been the attitude of end users towards it.
It's really simple: encryption slows network connections. In every way. It takes longer for the server to prepare a webpage for delivery (because it has to encrypt it first). It takes longer to ship it across the network (because encrypted pages are just bigger than the same page unencrypted). It takes longer for your browser to draw the page on the screen (because it has to unencrypt it first). And if everyone were to do it, the increase in size of individual pages would contribute to further network congestion (though, frankly, against spam, we might not notice.)
And the users, the consumers, the customers -- that would be all of us -- wouldn't stand for it. After all, "who would want to break into my email??" If users didn't understand why encryption mattered, they sure understood performance. Users voted with their feet. "Nothing I say is all that important. I don't have anything to worry about. Why would I put up with an irritating slow down when I don't have anything in need of protecting?"
I'm not trying to shame or blame you. Performance -- speed -- is a real and valuable consideration. You're not wrong to care a lot about it. I'm right there with you.
What's happening right now for a lot of you is that you're realizing that there are also other considerations, against which performance needs to be balanced. Your priorities are shifting.
Web 2.0 sites will start providing end-to-end encryption when you, the consumers, demand it, and not a second before. When you become willing to sacrifice some snappiness of response for improved security, and you make that plain to service providers that encryption is something you will not merely tolerate, but actively seek out, then you will get encryption.
And this isn't just about encryption. It's about just about every security measure known to programmer. Mostly people have stopped whining about having to remember passwords, but that alone was an uphill battle. Security typically imposes trade-offs with not just performance/speed, but:
This is hard. There is no way around it.
But here's the thing. To the extent that users demand improved security, to that extent these tradeoffs will start getting whittled away. If everyone felt as strongly about whole-session HTTPS for their web email as they do about the ability to make the font of their out-going emails purple, then there wouldn't be a web email service that didn't support HTTPS. If everyone felt as strongly about not passing messages in the clear as they do about sending attachments, in short order, everybody would start signing one another's keys. If you couldn't get people to sign up for your discussion list because it wasn't encrypted, you'd better believe there'd be a whole lot more encrypted list servers to choose from. And so forth.
You, gentle users, need to want it. You need to demand it. You need to choose these things as matters of policy, and also as matters of principle: the principle of, "It might not matter a whole lot to me (right now) but by voting with my feet, I drive the development and adoption of security features and applications which benefit everybody in the long run."
So what can you do?
0) Turn on pervasive HTTPS however and wherever you can. The companies you connect to via HTTPS will start routing more resources to supporting HTTPS. Yes, they can tell that you're using it -- you'd better believe they can tell -- and it sends one of the clearest signals that you're serious about wanting it.
You can extend this principle to just about any security feature or product. Even if you think you don't need it right now, your using it helps make it available to more people. Sometimes, that's in a really direct fashion: participate in Tor, and you make Tor bigger and more secure for all Tor users.
While you're at it, please start using sftp instead of ftp to be uploading files to your webserver. Or use scp.
1) Contact web 2.0 service providers (e.g. Amazon) via their support services and politely ask how to turn on HTTPS pervasively, "So my cookies can't be grabbed by firesheep, and my account compromised". Note the phrasing: writing to ask, "I can't figure out how to do this, can you tell me how", implies that you assume they would provide such a thing. Make them write back to you, saying, "Well, actually, you can't", so you can turn around and reply, "This seems very important. Could you submit this, then, as a suggestion to your development team?"
This is, BTW, how we got health insurance companies to stop putting SSN numbers right on insurance cards -- a whole lot of mostly computer programmers and sysadmins politely asking for an alternative, over, and over, and over. In the immortal words of the HR Benes person who was signing me up when I was hired at techjob, "Oh, you're in IT, you'll want the alternative ID number instead of your SSN appearing on your card..." It shouldn't just be the folks in IT who are offered more secure versions of things; everybody should!
Now, when you ask for pervasive HTTPS, expect to hear, "We can't afford to." This is, for sites like LJ, a very big issue. The performance hit on the servers for something like universal pervasive HTTPS is huge. You don't have to argue with them, you know. It's enough that they heard the request. But if you want to, tacks you might try include sympathy, re-emphasizing its importance, "Well, I hope you'll consider it anyways", and blackmail ("I'm not sure I feel I can continue using your service...") if you feel so sincerely. Don't try to argue into capitulation -- the person you're talking to usually can't do a thing about it. Just give them something to pass on to the decision maker, and be sure you're a sympathetic voice the front-line worker is going to want to stick their neck out for.
1a) Also, start asking for these plugins and features for other browsers (and email clients, and specialty LJ/blogging clients, and...)
1b) Don't let perfectionism get in your way; you don't have to have to completely harden your system to be making a positive contribution. Do what you can, take the risks you feel you must, and leave the rest for another day. Try to improve a little bit, every time opportunity presents.
2) Evangelize. (NICELY please.) Change the public discourse about security. Start talking about these things in your own journal and elsewhere. Start educating other people about the issues, and trying to enlist them in helping increase the demand for improved security. Pass on the word that the reason for using these things isn't just to improve the security of one's own accounts, but to be part of a movement to improve security for all people. This is a form of being the change you want to see in the world.
People often say that just blogging about something is useless for making real changes in the world. In this case, they're wrong. Talking this issue up online -- what second wave feminism coined consciousness raising -- is actually incredibly useful and even necessary. This is going to need to be a mass movement to get anywhere. So start telling the masses. Pass it on.
3) Facilitate. If you can help out a fellow user, provide some security benefit to another, write up a how-to and post it, do so. Pave the path for others. Especially if you figure out how to do something tricky, "Oh, hai, I managed to compile it on my Mac running 6.0.9!" share the lesson.
4) If you're a coder, do what you can within your organization or working on your products to address these security concerns.
4a) Consult with other people not like you about just what the relevant threat models are. One of the chronic problems has been developers industriously oversolving the wrong problems (as defined as "not the problem huge masses of users need solved") to the neglect of the real problems. This results in products which are not adopted because they don't solve the problems of the users. Here's a hint: any security application which requires the user to have root/administrator access to install or run it is not going to be usable for a huge number of users; it means it can't be used in some of the least secure environments which most need security help, such as public library computers and in computer labs in schools, not unless it's rolled out by the authorities. Also, particularly on Macs, access to the Terminal is often locked out on public computers, so command line solutions aren't.
Finally, 5) computer programmers -- who are, usually, after all, also users -- have for decades been struggling to get people to take these things seriously. This is why they keep sharing these frightening stories which seem so "alarmist": to try to get you to share enough of their alarm to be willing to cooperate in addressing the problem. They've been out in front on these issues, because they were the power users. Power users: you know, the people who use the application more than anyone else, learn how all the features work and where all the bugs are, and what the workarounds are. But now you are power users, too. You live in these applications, too, now. Welcome to the team.
So, please, listen to your geeks when they tell you something is a security problem, because they've been around this block before. I'm not asking you to listen uncritically, or to obey unthinkingly. To the contrary, you should always gently check to see if they're just whining by asking the $10k question, "Is there something we should be doing about this?" and seeing what you get. (It should never be hard to toggle a geek into problem solving mode, though, the response you get may be "that's hard to say", which is, in fact, a manefestation of problem solving mode. It's the little spinning beach ball of technical speech.)
By "listening", I mean "humor the possibility they are saying something true and important, instead of blowing them off" and "asking thoughtful questions to learn more". Often, all the alarming geek is asking of you is to understand that there could be a serious problem than needs thinking about -- not sweeping under the rug -- and being an educated consumer of online services, who demands better security.
In regards to the previous post (Re firesheep), you might reasonably ask, "What the hell? If by Web 2.0 sites using this here 'encryption' stuff they would protect our accounts, why aren't they doing that? What's the hold up?"
There are several hold ups. And one of them is you.
Implementing encryption solutions has some serious technical challenges, but one of the worst problems is social.
I speak as a web developer. I live in this world, professionally, and have done for a decade. And I am here to tell you, one of the things sapping the will of website owners to do what is necessary for end-to-end encryption has been the attitude of end users towards it.
It's really simple: encryption slows network connections. In every way. It takes longer for the server to prepare a webpage for delivery (because it has to encrypt it first). It takes longer to ship it across the network (because encrypted pages are just bigger than the same page unencrypted). It takes longer for your browser to draw the page on the screen (because it has to unencrypt it first). And if everyone were to do it, the increase in size of individual pages would contribute to further network congestion (though, frankly, against spam, we might not notice.)
And the users, the consumers, the customers -- that would be all of us -- wouldn't stand for it. After all, "who would want to break into my email??" If users didn't understand why encryption mattered, they sure understood performance. Users voted with their feet. "Nothing I say is all that important. I don't have anything to worry about. Why would I put up with an irritating slow down when I don't have anything in need of protecting?"
I'm not trying to shame or blame you. Performance -- speed -- is a real and valuable consideration. You're not wrong to care a lot about it. I'm right there with you.
What's happening right now for a lot of you is that you're realizing that there are also other considerations, against which performance needs to be balanced. Your priorities are shifting.
Web 2.0 sites will start providing end-to-end encryption when you, the consumers, demand it, and not a second before. When you become willing to sacrifice some snappiness of response for improved security, and you make that plain to service providers that encryption is something you will not merely tolerate, but actively seek out, then you will get encryption.
And this isn't just about encryption. It's about just about every security measure known to programmer. Mostly people have stopped whining about having to remember passwords, but that alone was an uphill battle. Security typically imposes trade-offs with not just performance/speed, but:
- Convenience -- my PCP's office does serious, end-to-end encrypted online communication. But it means that when my PCP emails me, it doesn't go right into my email. I get a notification that I have email waiting on their system, and have to go log in over there to read it. I have to go through extra steps just to find out the message said, "OK, I'll do that."
- Ease of use -- Email encryption is still to cry. You know, if I have trouble remembering how to use something....
- Diversity of applications -- Finally found an end-to-end encrypted email list server. Exactly one. And it works with exactly six email clients. (I wonder if any of them handle encrypted email on handhelds. Gmail mobile, anyone?)
- Compatibility -- My wifi-capable Palm T|X + Mac system is never, ever going to be able to speak WPA2 Enterprise. The widget from Palm, if it is even still for sale, which AFAICT, it isn't, is only compatible with Window 2000/NT/XP. So I can't use WiFi at techjob, because, reasonably enough, they use real security. So I lose.
- Adoption -- All interesting security problems are partnerships. Are you willing to only engage in online communications with those who are also keeping up their end of the bargain? Are you willing, as someone on my flist suggests, to "unfriend" people who are cavalier about their security, and in being so expose you to risks? What if your grandmother isn't willing to use PGP?
- Power -- There are all sorts of powerful cool features that you can only have if you're unconcerned about anyone ever using those powers for evil. See recent discussion about geolocation risks, e.g., and previous discussion of issues with OpenStalkerSocial. There are lots of things where the downside of "And you can do X!" is "OMG you can do X!"
- Trust -- Most security requires the user to trust third parties, and, really, how should the users decide who they should trust or not? How does one determine the comparative merits of trusting a large impersonal corporation populated by staff who might not be very concerned with your security vs. a personal social contact with whom one might wind up having personal conflict and who is certainly not available 24/7 to respond to emergencies?
- Expense -- All that increased server and network load means the same volume of transaction now encrypted requires more bandwidth, more MIPS. And the software to participate in secure services may be costware. Sometimes security is the "pro" feature you have to pay money for.
This is hard. There is no way around it.
But here's the thing. To the extent that users demand improved security, to that extent these tradeoffs will start getting whittled away. If everyone felt as strongly about whole-session HTTPS for their web email as they do about the ability to make the font of their out-going emails purple, then there wouldn't be a web email service that didn't support HTTPS. If everyone felt as strongly about not passing messages in the clear as they do about sending attachments, in short order, everybody would start signing one another's keys. If you couldn't get people to sign up for your discussion list because it wasn't encrypted, you'd better believe there'd be a whole lot more encrypted list servers to choose from. And so forth.
You, gentle users, need to want it. You need to demand it. You need to choose these things as matters of policy, and also as matters of principle: the principle of, "It might not matter a whole lot to me (right now) but by voting with my feet, I drive the development and adoption of security features and applications which benefit everybody in the long run."
So what can you do?
0) Turn on pervasive HTTPS however and wherever you can. The companies you connect to via HTTPS will start routing more resources to supporting HTTPS. Yes, they can tell that you're using it -- you'd better believe they can tell -- and it sends one of the clearest signals that you're serious about wanting it.
You can extend this principle to just about any security feature or product. Even if you think you don't need it right now, your using it helps make it available to more people. Sometimes, that's in a really direct fashion: participate in Tor, and you make Tor bigger and more secure for all Tor users.
While you're at it, please start using sftp instead of ftp to be uploading files to your webserver. Or use scp.
1) Contact web 2.0 service providers (e.g. Amazon) via their support services and politely ask how to turn on HTTPS pervasively, "So my cookies can't be grabbed by firesheep, and my account compromised". Note the phrasing: writing to ask, "I can't figure out how to do this, can you tell me how", implies that you assume they would provide such a thing. Make them write back to you, saying, "Well, actually, you can't", so you can turn around and reply, "This seems very important. Could you submit this, then, as a suggestion to your development team?"
This is, BTW, how we got health insurance companies to stop putting SSN numbers right on insurance cards -- a whole lot of mostly computer programmers and sysadmins politely asking for an alternative, over, and over, and over. In the immortal words of the HR Benes person who was signing me up when I was hired at techjob, "Oh, you're in IT, you'll want the alternative ID number instead of your SSN appearing on your card..." It shouldn't just be the folks in IT who are offered more secure versions of things; everybody should!
Now, when you ask for pervasive HTTPS, expect to hear, "We can't afford to." This is, for sites like LJ, a very big issue. The performance hit on the servers for something like universal pervasive HTTPS is huge. You don't have to argue with them, you know. It's enough that they heard the request. But if you want to, tacks you might try include sympathy, re-emphasizing its importance, "Well, I hope you'll consider it anyways", and blackmail ("I'm not sure I feel I can continue using your service...") if you feel so sincerely. Don't try to argue into capitulation -- the person you're talking to usually can't do a thing about it. Just give them something to pass on to the decision maker, and be sure you're a sympathetic voice the front-line worker is going to want to stick their neck out for.
1a) Also, start asking for these plugins and features for other browsers (and email clients, and specialty LJ/blogging clients, and...)
1b) Don't let perfectionism get in your way; you don't have to have to completely harden your system to be making a positive contribution. Do what you can, take the risks you feel you must, and leave the rest for another day. Try to improve a little bit, every time opportunity presents.
2) Evangelize. (NICELY please.) Change the public discourse about security. Start talking about these things in your own journal and elsewhere. Start educating other people about the issues, and trying to enlist them in helping increase the demand for improved security. Pass on the word that the reason for using these things isn't just to improve the security of one's own accounts, but to be part of a movement to improve security for all people. This is a form of being the change you want to see in the world.
People often say that just blogging about something is useless for making real changes in the world. In this case, they're wrong. Talking this issue up online -- what second wave feminism coined consciousness raising -- is actually incredibly useful and even necessary. This is going to need to be a mass movement to get anywhere. So start telling the masses. Pass it on.
3) Facilitate. If you can help out a fellow user, provide some security benefit to another, write up a how-to and post it, do so. Pave the path for others. Especially if you figure out how to do something tricky, "Oh, hai, I managed to compile it on my Mac running 6.0.9!" share the lesson.
4) If you're a coder, do what you can within your organization or working on your products to address these security concerns.
4a) Consult with other people not like you about just what the relevant threat models are. One of the chronic problems has been developers industriously oversolving the wrong problems (as defined as "not the problem huge masses of users need solved") to the neglect of the real problems. This results in products which are not adopted because they don't solve the problems of the users. Here's a hint: any security application which requires the user to have root/administrator access to install or run it is not going to be usable for a huge number of users; it means it can't be used in some of the least secure environments which most need security help, such as public library computers and in computer labs in schools, not unless it's rolled out by the authorities. Also, particularly on Macs, access to the Terminal is often locked out on public computers, so command line solutions aren't.
Finally, 5) computer programmers -- who are, usually, after all, also users -- have for decades been struggling to get people to take these things seriously. This is why they keep sharing these frightening stories which seem so "alarmist": to try to get you to share enough of their alarm to be willing to cooperate in addressing the problem. They've been out in front on these issues, because they were the power users. Power users: you know, the people who use the application more than anyone else, learn how all the features work and where all the bugs are, and what the workarounds are. But now you are power users, too. You live in these applications, too, now. Welcome to the team.
So, please, listen to your geeks when they tell you something is a security problem, because they've been around this block before. I'm not asking you to listen uncritically, or to obey unthinkingly. To the contrary, you should always gently check to see if they're just whining by asking the $10k question, "Is there something we should be doing about this?" and seeing what you get. (It should never be hard to toggle a geek into problem solving mode, though, the response you get may be "that's hard to say", which is, in fact, a manefestation of problem solving mode. It's the little spinning beach ball of technical speech.)
By "listening", I mean "humor the possibility they are saying something true and important, instead of blowing them off" and "asking thoughtful questions to learn more". Often, all the alarming geek is asking of you is to understand that there could be a serious problem than needs thinking about -- not sweeping under the rug -- and being an educated consumer of online services, who demands better security.