Internet policy Shame Artist extraordinaire Chris Soghoian has struck again! Chris recently shamed the online advertising industry into improving their privacy practices with his Targeted Advertising Cookie Opt-Out (TACO) plug-in for Firefox. Now Chris has set his sight on the security practices of cloud service providers.
A letter released this morning, signed by 37 leading online security experts (and organized by Chris), calls on Google to offer persistent SSL (HTTPS) encryption by default for all Google services—or at the very least, to make more visible the option currently given to users to opt-in to use SSL for all communications. Google, in its response, indicated that it was already “looking into whether it would make sense to turn on HTTPS as the default for all Gmail users.”
While Google’s response identifies some clear problems with implementing persistent SSL for all users (esp. connection speed), few would deny that it makes sense for webmail providers to encrypt all traffic using SSL, rather than sending email data “in the clear,” which risks interception by hackers. We at PFF hold no brief for Google, in fact we have found ourselves disagreeing with them on many other occasions on a range of issues (most notably net neutrality mandates). Nonetheless, on this front, Google has long been a leader, having offered SSL since Gmail launched and having begun providing the persistent HTTPS option last summer while most of their competitors still use SSL only for the initial authentication that occurs when a user first signs in. While the letter focuses on Google and webmail in particular, this issue has far broader implications for all online cloud service providers.
No Free Lunch: The Costs of Encryption
Gmail, Yahoo! Mail, Hotmail, etc. are, of course, “free” (i.e., ad-supported). Google in particular has lead the way in increasing the functionality offered in Gmail, not just constantly increasing the total storage space provided to every user (now over 7GB), but regularly adding innovative new features—at no charge to users.
Offering persistent SSL is resource-intensive, because encryption requires computing power on the server side. Google currently spends billions on the servers that run all Google’s services, including Gmail—$2.4 billion back in 2007, when the company was much smaller. Google’s pricing for their App Engine offers some insight into cost, putting a cost of $0.10/CPU computing cycle. But without knowing what their actual cost is or how many CPU computing cycles the average Gmail user might consume per year using persistent SSL, it’s difficult to translate this price into an actual estimate of the cost of providing persistent SSL. Thus, while there are no hard numbers on how much Gmail costs Google to provide or how much more it would cost to provide persistent SSL for every user by default, both costs are clearly substantial. Chris himself provides a shot-in-the-dark guess that SSL-encrypted communications might require as much as six times the server resources as unencrypted communications. I’d love to know where Chris came up with that guess, whether the upper-bound might be even higher, and how he thinks smaller operators would pay for that cost.
Indeed, Chris’s letter does not discuss the cost of providing SSL at all, mentioning the word “cost” just once, and in a completely different sense: “Other Google applications demonstrate that security need not come at the cost of performance.” This is perfectly consistent with Chris’s general response to the costs of regulation: “Your broken business model is not my problem” (which sounds more charming in Chris’s elegant British English).
But just as Chris is correct that “Defaults matter,” it is even more true that “Costs matter.” Google appears to take the question of how much it costs to provide SSL off the table: “in this case, the additional cost of offering HTTPS isn’t holding us back.” But this is by no means a dismissal of the importance of costs. Rather, Google is simply saying that it has already decided that the advantage of providing persistent SSL are worth the costs. Every advantage to users in terms of greater security is, of course, also an advantage to Google as it competes for customers. While Gmail may have the highest profile among webmail companies, it still lags far behind Yahoo! Mail and Microsoft’s Hotmail in market share: As of February, Yahoo!’s market share was 56%, Microsoft’s 19% and Google’s 11%. Offering increased security, as Google already does with the full-SSL opt-in, is simply a way for Google to gain a competitive advantage over its rivals. One can only imagine the barrier to entry such an expensive default, if mandated or simply expected, will create for new, smaller competitors to Google, Microsoft, Yahoo! and other web titans across a wide range of cloud services.
Google’s apparent agreement with Chris and his band of cybersecurity experts conceals a more fundamental difference of perspectives. While I consider Chris a good friend, what separates us him, and what separates him from Google, is the question of trade-offs. Chris exemplifies what the economist and philosopher Thomas Sowell called the “Vision of the Anointed.” As the best and brightest in society (“the talented few”), the Anointed are often right, as Chris certainly is here on some level: Persistent SSL is a great thing and most Gmail users would probably be better off with it once Gmail irons out all the kinks in implementing it. (Indeed, I had already opted-in to using persistent SSL reading before Chris’s letter.)
No, the problem with the Anointed is not that they are necessarily wrong, but that they focus on “Solutions” to problems, while those with the “Tragic Vision” focus on the “Trade-offs” inherent in the constraints of reality. For the Anointed, seeking to impose their preferences on others, Sowell notes:
it is simply a question of choosing the best solution, while to those with the tragic vision the more fundamental question is: Who is to choose? And by what process, and by what consequences for being wrong? … it is so easy to be wrong—and to persist in being wrong—when the costs of being wrong are paid by others. (pp. 135-36).
Google’s response focuses on one important trade-off: that made by users deciding between added security and a slower Gmail connection. Individual preferences on this choice might vary, even among fully-informed users: For example, some Gmail power users may prefer speed over security, knowing that the risks addressed by are lessened because they do not take their desktop PCs to unsecure Wi-Fi hotspots at, say, the local coffee shop.
But there is a more fundamental trade-off at stake: While Google already offers persistent SSL for free to all users and says that they intend to make this the default setting in the near future, using SSL for everyone will be expensive and that cost will ultimately be borne by consumers as well as by Google (and other webmail operators that follow suit). The cost of providing SSL might mean, for example, that Google will provide less storage space or other innovative Gmail features than it would otherwise have done, because while the politicians in Washington can simply print more money to put a “chicken in every pot” (and a mortgage in every subprime borrower’s hands), Google’s resources are necessarily limited. In short, even in the world of “Free!” content and services, there is no free lunch! In a world of scarce resources (a/k/a reality, even the reality of the digital economy), we must make trade-offs.
Again, Chris may well be correct that the security benefits of SSL are worth this particular trade-off but it’s important to distinguish between two different kinds of decisions. Again, Sowell makes the point brilliantly:
trade-offs must be incremental rather than categorical, if limited resources are to produce optimal results in any social system as a whole. Despite the importance of incremental trade-offs, the language of politics is filled with categorical rhetoric about ‘setting priorities,” “providing basic necessities.” or “assuring safety” in foods, medicines, or nuclear power. But incremental decisions differ as much from categorical decisions as trade-offs differ from solutions. If faced with a categorical choice between food and music, every sane person would choose food, since one can live without music but not without food. But if faced with an incremental choice, the decision could easily be just the opposite. If food were categorically more important than music, then we would never reach a point where we were prepared to sacrifice resources that could be used to produce food, in order to produce music. Given this premise, Beethoven, Brahms, and Bach should all have been put to work growing potatoes, instead of writing music, if food were categorically more important.
Online “security” (like online “privacy”) is, like food or physical safety, undeniably a good thing. But we must still make trade-offs between security and the other things with which is necessarily competes. Google currently runs vast server farms, but still has only a certain number of CPU cycles to use for a variety of competing purposes. Spending that scarce resource (and the money that ultimately pays for it) on persistent SSL necessarily means being able to offer less of other things across the wide range of services Google offers. It is in recognition of such unintended consequences that Sowell concludes that:
many a sound and beneficial principle becomes a dangerous absurdity when it becomes a fetish. That is why any categorical principle must be assess not only in terms of its soundness as a principle, but also in terms of what happens when that principle is applied categorically.
So, what would happen if this insistence on persistent SSL were “applied categorically?”
Impact on the Competitive Landscape
While Google may be able to “eat” the cost of persistent SSL for all its Gmail users, mandating the use of persistent SSL may create a significant barrier to entry that could keep smaller providers out of the market. Even shaming a leading webmail provider like Google into voluntarily increasing their security offering may accomplish the same result by raising consumer expectations. Indeed, this is what competition is all about!
For a large webmail provider like Yahoo!-already struggling to find its way in a rapidly evolving competitive landscape for web content, services and advertising despite its 56% webmail market share-the cost of providing persistent SSL for their enormous installed base of users will necessarily reduce their resources available to compete with Google in webmail and on other fronts. For Microsoft, every dollar spent on upgrading Hotmail security could have been spent on improving Bing, Microsoft’s new search engine, which seems capable of posing a significant challenge to Google in the search market.
In general, increasing the cost of providing a service will necessarily tend to make that service less competitive. If there are fewer companies competing to offer webmail (and other related products like calendar services), there will be less pressure on each of them to compete in non-price terms such as…. security and privacy protection. Thus, in the real world, fetishizing security can actually lead to less security.
The Cost/Benefit Approach to Security Improvements
Indeed, while the full use of SSL is an obvious way to improve the security of webmail, it is not obvious that it is the most cost-efficient way to do so. If the precise costs of using persistent SSL for all users are substantial but unclear, it is impossible to evaluate whether user security might be improved more by prioritizing scarce resources to deal with other threats.
The threat posed by unauthorized account access via cookie stealing and packet sniffing appears to be far smaller than other less obvious security threats, such as permitting the use of weak passwords, duplicating passwords across accounts, reliance on poor secret questions, the accessing of accounts at unsecured public terminals, and the failure of users to log out. Likewise, threats to end-user security and privacy such as cross-site scripting attacks or cross-site forgery requests account for a far greater portion of internet-related security incidents. There may be no technological “silver bullet” for these problems, but they may represent the “low hanging fruit” for improving security at a much lower cost.
Again, the question is not just whether the Anointed are right, but who is to decide among various options such as persistent SSL, user education and changes in user interface design.
HTTPS Über Alles: Where is This Going?
Google indicated that they’re exploring turning on persistent SSL (HTTPS) for all Gmail users, but says nothing about other Google services. Chris’s letter, however, asks Google to adopt HTTPS for Google Docs and Calendar, and goes on to mention Facebook and MySpace as companies that leave their users “vulnerable to data theft and account hijacking” because they do not use HTTPS.
So just how far should the adoption of HTTPS go? Chris’s draft “Caught in the Cloud” paper repeatedly argues that all cloud services should adopt persistent SSL. Yet even he recognizes that e-mail may be uniquely sensitive:
While most users’ word processing documents or photo collections may not be that valuable to a fraudster, an email account can have considerable value – due to the fact that inboxes routinely contain passwords and account information for other websites. For example, many Web sites will resend a password to a user’s email address in the event that the user forgets her password. Thus, a poorly secured email account can be leveraged to gain access to a victim’s bank account, brokerage account or online health records. (p. 15)
Here, Chris seems to recognize the need to make real trade-offs. But his coalition letter draws no such distinction, and even if it did, the more important point is that the Anointed think they know better how to draw these distinctions than anyone else—especially the companies who actually offer cloud services.
So what about Facebook messaging, Twitter tweets, and other social networking communication tools? How should “we” decide which of these services really merits persistent SSL? More important, who is this “we,” anyway? Who’s actually going to make these decisions? Rather than trusting in the “systemic process” of competition among cloud computing companies, for whom security can be an element of non-price competition, the Anointed presume to make these decisions for everyone else.
Paying for SSL
In a world of trade-offs, it’s important to look not just at the opportunity cost of providing features like persistent SSL, but also at the additional sources of revenue that could cover the costs of cloud computing features like SSL. If we can “grow the pie,” the trades-offs made to support persistent SSL will not be so painful. Two potential revenue streams seem obvious.
First, Google and other cloud service providers could simply charge for persistent SSL. For instance, Google currently charges $50/year/user for customized, ad-free Google Apps email accounts.
Second, if the advertising that supports webmail and other cloud services were more profitable, Google could afford more “guns and butter”: persistent SSL for everyone and continued expansion of storage space and roll-out of new Gmail features. This is precisely why Google, Yahoo! and other online advertising companies want to offer “Interest-Based Advertising” that is tailored to a user’s interests based on data about their web surfing. Unfortunately, the Anointed have so fetishized “User Privacy” that they are blind to these trade-offs, and fail to recognize that limiting targeted advertising in the name of “Privacy” may compromise “Security,” just as mandating “Security” protections may actually reduce competitive pressures to increase “Privacy” protections.
Thus, as Sowell emphasizes, we must understand that trade-offs cannot be made in isolation because “What can be afforded seriatim vastly exceeds what can be afforded simultaneously.” That is, we must make “trade-offs within an overall system constrained by inherent limitations of resources, knowledge, etc.” It is precisely because that task is so challenging that we must proceed cautiously and resist the insistence of the Anointed that there is an “urgent need for action to avert impending catastrophe.”
Other Options: User Empowerment & Education
Chris’s letter calls for persistent SSL by default in the belief that users do not know enough to protect themselves. In the alternative, the letter suggests four steps Google could take to help users make more fully informed choices. These suggestions seem generally reasonable, and it might well make sense to adopt them, but there are other means to address the ignorance of the “Benighted” than by presuming to decide which trade-offs Google should make in how it designs the user interface of Gmail for all users.
First, Google could present more information and a cleaner choice about persistent SSL during the initial account set-up process. In other words, when a user creates a new Google account, they would be told the pros and cons of persistent SSL and could then make a more informed decision about whether to use persistent SSL or SSL only for authentication. Since Gmail currently has only an 11% share of the webmail market, the vast majority of potential users would have to make these decisions at the point of initial sign-up, while the user interface for existing users would not be further complicated. This example illustrates just one way in which Google might be able to able to make better decisions about the trade-offs at issue than the Anointed, however well-deserved their credentials in the field of web security.
Second, Google could add more discussion of SSL to its existing online educational resources about user privacy and security. Google could expand its Privacy Center on YouTube to include detailed discussions about the potential risks of not using persistent SSL and easy-to-follow video tutorials about the pros and cons of HTTPS.
The Politics of Shame
A final word about tactics: I call Chris a “Shame Artist” in the best sense of the term. Shaming corporations is a key part of the reputational marketplace—something my colleague Adam Thierer has emphasized in his work [PDF p. 30] on online parental controls and child protection. People like Chris play a critical role in helping to raise public awareness of genuine problems, and to encourage companies to improve their practices. This dynamic has never worked as well, or as quickly, as it does in the online marketplace. But there are two important caveats to the beneficial role played by shame artists.
First, there is a fine line between (i) shining the spotlight of public attention on a problem and bringing reputational pressure to bear on the company responsible, and (ii) threatening such a company with regulation if you don’t get what you want. Here, as is often the case, Chris is playing dangerously close to that line. Chris’s “Lost in the Cloud” paper calls first for companies to change their practices voluntarily, then for mandating disclosure of SSL choices and risks, and then for mandates:
the government [could] regulate providers of cloud computing services, as it has already done in the banking and health industries. Banks are simply not permitted to let customers to make encryption a “choice,” just as car manufacturers are no longer permitted to make seat belts optional. We would prefer that regulators first forced cloud computing providers to display clear educational warnings before regulators go down the path of mandating specific technologies. However, if educational warnings failed to provoke a sufficient market response, stronger regulation might be appropriate.
At the very least, Chris is hanging the regulatory “Sword of Damocles” over the necks of cloud computing providers: The sword hasn’t fallen yet, but it threatens to drop at any moment if industry doesn’t cooperate.
Second, pressuring providers of free (ad-supported) services to offer more features risks increasing the deeply-rooted assumption that users of these services are somehow entitled to them, including whatever specific functionality the Anointed think ought to be included in the service. In fairness to Chris and his coalition, their letter does not specify how persistent SSL should be provided and he seems to be content with the idea that Google might charge for the service—a recognition of a trade-off that separates him from the more extreme among the Anointed. But once Congress, AGs and other government officials start rushing in to do Chris’s bidding, subtly or not-so-subtly coercing cloud service providers, I hope he isn’t surprised when they come back knocking on those same doors asking for more favors in the name of “Internet security.” With one hand they giveth (what Chris wants); with the other they might eventually take away (something Chris and his comrades find important).
But anytime a company is pressured to give away even more of what it’s already giving away for free, the expectation of a getting a “Free Lunch” grows. (“Free dessert, too? Don’t mind if I do!“) Worse, if companies appear to cave in to this pressure without acknowledging the trade-offs involved, they both add to that expectation and encourage future attacks by shame artists, since they are signaling a willingness to cave-in. This is essentially the same moral hazard problem as created by negotiating with terrorists. I certainly don’t mean to compare either Chris’s goals or his methods to those of violent extremists or to trivialize his arguments. But the dynamic created by weak responses to shaming in this context is nonetheless analogous: Every time a company says “Why not? Cost is no issue!,” they make it that much more difficult for themselves and others to say, in the future, that cost sometimes will require more obvious trade-offs like charging users for the feature demanded by the Anointed. At some point, such “upsells” may become so politically untenable that the practical choices are (i) not offering the feature at all and (ii) offering it to everyone for free (the costs of which will be borne somewhere else). I fear we may already have reached that point.
The Technology Liberation Front is the tech policy blog dedicated to keeping politicians' hands off the 'net and everything else related to technology.