Tuesday, May 25, 2010

Google announced on Friday the availability of a beta version of its secure search.

Secure search? Well, kind of. Google, of course, still retains all your search data. But users will now have the option of searching over an SSL connection. Just type https instead of http in the Google URL and your searches are safe from prying eyes, Google and your desktop notwithstanding.

The rushed timing of the latest announcement is no coincidence. Google has been in some serious hot water over the last few weeks for gathering data from insecure wifi connections using StreetView. Unlike previous Google privacy $@#%-ups, StreetView wifi-gate has users, and especially governments, genuinely annoyed. A big American company driving by in a van and kinda sorta intercepting wifi traffic understandably rubs a lot of folks the wrong way, especially in Europe.

There is a certain delicious irony here. Google gets busted for spying on unencrypted wifi connections, and responds by offering encrypted search. Google is basically saying that you had better think about encrypting your search results, because there are a lot of crazy folks out there who might be trying to listen in. Heck, even we might be accidentally listening in!

Ironic or not, at least this makes some sense. Last week I wrote about Facebook trying to address a growing privacy uproar by offering a totally unrelated security option. While offering a rare mea culpa for the wifi snooping, with secure search Google is also not-so-subtly castigating users for their use of insecure connections. A bit like Toyota reminding users about the importance of seat belts...

[Since we're on the wifi topic, one quick digression - I don't believe for a minute that Google has any interest in spying on user wifi data. With so much data on so many users, the last thing the company needs is to physically go to users to get their information. I take at face value the claim that a "programming error" was responsible for the extraneous data collection. Unlike Facebook, Google has a deeper well of general public sympathy to draw on and my theory is that the public, if not necessarily the legal, aspects of this incident will quickly blow over.]

But back to secure search, which has been in the works for a while and is much more than a response to the wifi incident. Cynics say that secure search is just a ploy by Google to keep precious search data from the ISPs. To me that doesn't hold much water. Secure search will never comprise more than a tiny slice of overall Google searches unless it is the default. And I don't see that happening any time soon.

At the risk of overestimating the importance of the security profession, I would argue that one of the main motivations behind the new service is Google's interest in placating the security purists within organizations considering its enterprise services. As the biggest cloud service provider in the world, Google's entire corporate future is tied into trust and security in web applications. If Google wants to convince users to ditch desktop applications and behind-the-firewall servers in favor of its web-centered universe, it needs to convince enterprises that it takes security uber-seriously. By being the first major player to offer to secure pre-authentication search data, Google casts itself as a cutting edge provider of secure cloud services.

But does secure search fulfill an actual security function that justifies its cost? Or is it a case of security overkill meets security theatre?

Searching away from prying eyes

Let's start with what Google searches over https achieve. By encrypting traffic, search traffic will be safe from network sniffers.

Here's my best stab at a list of people/entities you might not want seeing your Google searches:

Secure search does nothing for (1). In case (2), your employer is probably not terminating SSL connections, but they may very well be, so you can't really count on your searches being secure. With (4), your government or ISP have enough information on you (like your entire traffic history) that your search history becomes largely irrelevant.

That leaves (3). The only real advantage of secure search is protecting you in random networks you might be connecting to. This seems like a pretty limited use case. And anyone sufficiently security conscious is already tunneling their traffic on public networks rendering moot the privacy advantage of secure search.

How did you get here?

There is one big privacy advantage to secure search - referrer headers are no longer passed, so the web page you are landing on no longer knows how you got there. The vast majority of Internet users do not realize a simple fact that is obvious to most of the security minded readers of this blog. When you search "furry animals" on Google, and land on www.myfurryanimals.com, the webmaster of the latter sees that you landed there by searching "furry animals". The entire web analytics industry is built around this fact.

But you don't need SSL to disable referrer headers. And besides, if someone is so concerned about privacy, they might be better off getting an anonymous proxy. Proxied traffic usually uses encrypted protocols, so at that point using secure search becomes superfluous.

I have no idea what the performance or functionality hit on secure search will be, but for now I don't see the numbers adding up in favor of the service. Searching on the beta Google secure search site seems slightly slower than regular http Google, (although admittedly from the confines of a crowded New York cafe on a Sunday evening). So here's my back-of-the-napkin calculation: I probably do 100 Google searches a day. If each of those is 1 second slower (and I'm just making up the numbers here), is it really worth an extra 1min and 40 seconds of my time every day to hide my Google search history from a hypothetical person who might want to look at it?

The large majority of users have so many toolbars, widgets, and logged in applications running at the same time that the entire concept of SSL encrypting their search traffic is ridiculous. But even for privacy conscious users this seems like one proverbial bridge too far. Secure search might give users a false sense of privacy with little tangible benefit.

An interesting project by the Electroric Freedom Foundation called Panopticlick shows that your browser basically provides servers enough information to be uniquely identifiable. With all the fonts, plugins, and other settings your browser has, even with an anonymous proxy a website can identify you as a return visitor. For the average user, online privacy is a bit of a heads they win, tail you lose proposition. No matter what measures they are taking, it turns out that they are still traceable online.

All this certainly should't be construed as meaning that secure search is useless. Whatever one thinks of Google's privacy policies, they do offer a rich set of user security configuration options. With options like tying password reset to a mobile number, showing the last IP addresses that logged into a Google Account, and default SSL for many enterprise applications, Google offers a significant arsenal of security options that is more robust than many of its competitors. I'm just not sure if secure search adds much to this portfolio.

Friday, May 21, 2010

Facebook can't seem to catch a break. Just this Wednesday an XSRF bug was announced that gave access to birthdates users had designated as private.

Not that Facebook users care. I would bet dollars to proverbial donuts that no more than 0.01% of Facebook users has ever heard of XSRF. And more importantly, I would bet that almost none of them has really suffered from these vulnerabilities. Bad security in social networks is a non-story. Lax privacy policies, on the other hand, are much more in your face. No user is going to notice an insecure version of Python running on your webserver. But share their data with unauthorized contacts and the same user might go beserk.

User apathy notwithstanding, Facebook is making some half-hearted attempts to calm the masses. The company announced last Thursday the ability to limit the devices from which an account can be accessed. But this attempt to soothe the raging Facebook villagers with sharpened pitchforks is misdirected. Users are concerned about who Facebook is sharing their information with, not how. Device authentication - a poor man's security control at the best of times - is an unnecessary inconvenience to the vast majority of users and an insufficient safety control for the truly paranoid.

Facebook are not fools of course. You don't build a business that engages every tenth adult on the planet without honing a pretty good sense for which way the wind is blowing. The company realizes that it is under no obligation to provide any real security controls to its users. Providing window dressing security such as device authentication is a good way to appear conscientious to a public that tends to conflate security with privacy. And in any case, the risk that device authentication addresses - preventing User A from logging in as User B - is the one area where Facebook and its users have a common interest.

So Facebook's mission is not entirely at odds with security. Facebook has an interest in providing application security insofar as it does not impede its vision of becoming the web's authoritative social platform (more on that in a bit). But beyond that, why would Facebook provide security that involves substantial resources or limits its collaborative abilities? Facebook may throw its users a security bone when in comes on the cheap, but the company is under no obligation to provide anything beefier.

Really? Here is a simple fact most security folks won't like - unless you are in a regulated industry you are under almost no specific obligation to offer secure web applications. Unlike privacy regulations, this statement is true across all major jurisdictions. Laws will limit whoyou can share data with, and in some cases like children whether information can be collected to begin with. But they impose virtually no requirements on small businesses on how or even whether they need to secure their data.

This means that anybody can fire up a web application and start collecting, storing, and processing data that may or may not be sensitive to its owner. And they can do this while being under almost no legal or business requirement to provide adequate security.

With hosting costs approaching zero and development frameworks hiding the uglier layers of the stack, this means that any old schmo can be in business in no time. Just like you can blog on Blogger without touching any code, you can now build some pretty impressive quasi-professional web apps without touching any real code. Millions of people have done exactly that.

But what about big apps? Surely the ubiquitous brand name web applications are subject to some sort of control that two guys in their garage are not? Well, not really. The fact is that many web 2.0 apps that are in common enterprise use are probably not more than 5 or 10 guys. They may look like big businesses, but the beauty of the Internet is the ability for small organizations to amplify their presence and take on the trappings of the big boys.

Today there are gazillions of sites out there that will do anything from storing files to reformatting reports that are operating with almost zero intentional application security. And its not just small or medium sized businesses. Even the big players are, at the end of the day, only subject to restriction on who they can share data with. Having mostly evolved from small start-up operations, they take an understandably minimalist approach to information security. Application security - in stark contrast to privacy - is basically a good faith effort.

The kerfuffle around Google's recent StreetView-wifi snafu is a good example of the priority of privacy over security. Apparently Google's StreetView had collected information from open wifi networks. Google has attracted a great deal of negative press and is facing numerous investigations in Germany and elsewhere for this. At the same time, the numerous security vulnerabilities that are frequently exposed at most large companies hardly register on the legal radar screen, and is certainly not something that will get investigated. You don't trigger an EU investigation by having too many bugs to patch in a given release or by using a vulnerable version of PHP.

The More Social, The Less Secure

That's not to say that security and privacy are totally unrelated in social networks. If Facebook wants to build a platform that others can plug into, it necessarily opens the application to vulnerabilities. A very good example of this is the recent hiccup with Yelp. Facebook's Instant Personalization exposed users to a cross-site-scripting vulnerability on Yelp that could harvest user data. Without the Yelp integration, this vulnerability would never have happened.

When it comes to social networks, there is no free security lunch. Collaborative services are by definition less secure. Facebook is meant to be collaborative and thus can never offer the same level of security as a more gated service. This is the same reason that Times Square cannot be secured in the same way an airport can. One is meant to be open and one is meant to be closed, or at least controlled. Although hundreds of security vendors may try to secure web 2.0 applications, robust security and social collaboration are ultimately opposing aims.

Of course there are numerous technological standards that are being built precisely to secure the web 2.0 world. The move to OAuth from BasicAuth (a transition that Twitter will be enforcing next month) is a good example. But from a business perspective, the raison d'etre of most social applications is the collaboration, not the security. When web services communicate, there is generally only one level of authentication required to reach the crown jewels. Unlike traditional applications, most web services only require one screw-up or misconfiguration to expose your data.

Social Media vs the Enterprise

This single-line-of-defense approach that most web 2.0 applications take is sufficient for most individual personal data. Your Facebook settings may limit photos of you drinking at a keg party from your work colleagues, but their accidental exposure is not such a big deal and is a risk most users are willing to assume. In our personal lives, there is no breach notification, limited personal financial liability, and a much lower expectation of due care. Even the recent mess-up exposing your friends' private chats on Facebook is probably met with a stuff-happens shrug by everyone not directly affected.

But enterprises should - in theory - be more cautious. Breaches can carry real costs, financial liability is more substantial, and there are often contractual obligations to provide security. Indeed while there might be no affirmative legal obligation for application providers to provide security, customers may very well be prevented from using their services if there is insufficient security. After all, most enterprises that deal in personal data are under some form of contractual obligation to reasonably protect that data.

Will this raise the bar for small providers of cloud services? Unlikely. As I have frequently ranted about in the past, in non-regulated industries these obligations usually refer to some dinosaur-like provisions about SSL and biometric readers at server room entrances. Unless a company is truly conscientious about applying the meaning of due and reasonable care, there are practically no legal or contractual security requirements to which web applications are subject. (This is of course not true of heavily regulated industries like finance, but most corporations are operating in much more loosely regulated spaces).

Many enterprises are driving full steam ahead with the integration of minimally secured third party web applications into the enterprise. The transition from walled-off silo to full member of the application ecosystem is well underway. We may not be in a Jericho-Forum world of perimeterless utopia, but we are in the awkward teenage state of integrating our IT environment with hundreds of smaller companies - through APIs, SDKs, and the like.

Much like real life, digital hookups put enterprises at risk - you no longer have to worry just about who you are with, but everyone they have been with and will be with in the future. And just like real life, the process of evaluating the safety of a potential application hookup is largely heuristic. With an increasingly promiscuous digital environment, we lose the ability to do a full battery of tests on each potential partner (and belated apologies for the lame analogy).

For individuals, the risks of collaborative web services are far outweighed by the benefits. That's the reason that Facebook has 400 million users and why thousands of popular applications with only the thinnest veneer of authentication thrive. This risk calculus will also hold for many enterprises, both large and small. For more security heavy environments, however, fundamental changes will be needed. For some environments it will take a lot more than device authentication to make today's handy web applications ready for enterprise prime time.