The recent announcement from an official MSFT blog that Windows 8 will allow sign-in to the machine with a Windows Live ID marks the final ascendancy of cloud identity systems. Until recently, there were two principal notions of  identity recognized by Windows.

1. Local accounts, maintained by that PC and recognized by no other machine. This is what a consumer might have on their machine at home: if there are 5 people in the household, each one gets a different account . Note that passwords are not  required; the accounts can be setup such that merely clicking on the user tile is enough. In this model accounts are used purely for customization: each person can pick a different background, shortcuts, have different applications start up when they login, their web browser remembers their unique history, etc. The identity can not be asserted anywhere else: in order to read email for example, the user has to type a different password to sign-in to their mail provider. (There is a subtlety here in that this password for Hotmail/GMail/Yahoo etc. can be cached, making the local Windows account act as a “key ring” or “credential store” for other cloud identities, but the Windows identity itself is not recognized in the cloud.)
2. Domain accounts: This is the enterprise scenario, where an IT department sets up an Active Directory system for central management of all computers in the company. Identities are then issued by the centralized system and recognized at by all machines that are members of the AD domain.  The user types in a username/password to logon to their laptop; this part of the experience is not changed. But the protocol used under the hood ensures that the same identity authenticated by those credentials is also good for accessing resources on a file share, sending a print job to the expensive color printer or downloading email from the local Exchange server the IT department runs.

Enterprise identity systems were the first to confront the challenge of integrating with the cloud. As basic functionality such as email, CRM, content management etc. were increasingly outsourced to web providers in the name of efficiency, some solution became mandatory to allow use of existing enterprise identity to authenticate to the cloud. Asking users to manage different passwords for each outsourced service quickly makes IT departments very unpopular– not that they have any political capital to burn, for the most part. Typically this is achieved by using a “bridging” solution that converts the brand of identity expression used in the enterprise eg crusty-old Kerberos, into a different format that is more in-tune with the fashionable standards on the web, which means typically angle-brackets and XML eg SAML.

While several companies market such bridging solutions for the enterprise market, until now the most sophisticated form of integration available to home users remained the old-school password manager: the local device will store all your passwords for websites, much like a keyring, the story goes, and once you login to that device you can use any key to unlock other doors out there. Variations on this theme, such as cloud-based password managers that allow roaming the keyring between different machines, remained the state of the art for PC and Mac platform.

In a sense this was understandable: being an open ecosystem, the PC had to cope with a myriad of different authentication systems, proprietary schemes vying to become standards  (mostly dead-ends it turned out) and incompatible usage models across the board: from the security conscious paranoid user to the convenience-driven casual web surfer.  Instead most of the innovation in simplifying the identity experience happened on relatively closed-platforms, what Jonathan Zittrain might have termed “appliances” with less-stringent requirements for integration beyond the services provided by the platform owner: iPhone, Android and ChromeOS proved how easy it is to use cloud identity when there is exactly one identity provider.

[continued]

CP

The announcement by MSFT that Internet Explorer 10 will have one browsing mode without plug-ins has naturally raised eyebrows. The move can be interpreted from two different angles:

1. Strategic strike aimed squarely against Adobe. By far the most dominant extension during the past decade has been Flash. Whatever limitations HTML and Javascript had– perceived or real– Flash was there to provide developers the escape hatch to add the all-important dancing squirrels to their website. MSFT made an ill-fated attempt to displace Flash with Silverlight. This crusade ended like many other homebrew technologies emerging out of Redmond in the past decade, in yet another confirmation  that MSFT is too constrained by regulatory attention and no longer freely wields the immense market power it once held for single-handedly introducing new de facto standards. Silverlight tanked. Its one prominent customer Major League Baseball– which may motivated porting the technology to OS X, lest Mac using fans were left out– dropped Silverlight after the 2008 season to go with Flash for online broadcasts.

It is not surprising to see MSFT embrace HTML5 in response. This is standard operating procedure in platform wars. If a company can not force its own technology (eg Silverlight) on consumers, the next best thing is for an open standard (HTML5) to win– verses ceding the ground to a different proprietary offering (Flash) from a major competitor.

2. A less cynical reading of the move is that it represents a return to a simpler, “purist” interpretation of the web. After going through several iterations in the span of a few short years, HTML became stagnant at version 4.01– that recommendation was published in 1999. Meanwhile the demands of web applications continue to grow, particularly after the dotcom bubble exploded and the remains gave rise to web 2.0. Into this void stepped Flash. There had been earlier attempts to “enhance” the web experience: ActiveX to bring the full power and perils of Windows native programming, Java before that with the promise of write-once-run-anywhere. For the first time with Flash developer demand and technology had a happy meeting in the middle.

The downside is Flash fabricated whole new “conventions” out of thin air, and resurrected privacy and security problems that had been already solved before in the context of web standards. Web browsers greatly limited interaction between websites to prevent security risks, the so-called same origin policy that underlies web security model. Flash invented its own cross-domain access rules, creating vulnerabilities on websites– even on sites that did not use Flash, a cardinal sin for a technology.

Privacy also suffered: tracking cookies were the big scare in 2000, a time that seems positively innocent by contemporary standards. Eventually better cookie management functionality in the web browser and a half-hearted at a new policy language tamed the problem– for “cookies” as they were defined at the time. Flash introduced its own notion of client-side storage which could be used to achieve the same tracking capability as regular cookies, yet remained outside the purview of privacy enhancements implemented over the years to manage regular HTTP cookies. This was a clear boon to web services with dubious intentions for tracking users. Sure enough a study in 2009 found that Flash cookies are commonly used as back-up measure by many popular websites, to recreate regular cookies that are deleted by users. (Granted HTML5 also introduced its own notion of local storage, but at least web browsers provided users the control over this functionality. For the longest time the only way to delete Flash cookies was to visit a web page hosted by Adobe, in sharp contrast from centralized browser settings.)

From this perspective, disabling plugins and imposing strict HTML5 semantics on the chaos happening inside a web browser is a good development. HTML5 has come a long way– much of the functionality (cross-domain communication with access control, multiple threads, better graphics, video support etc.) is being incorporated into the standards. The need for an escape hatch whether in the form of Flash, Java or Silverlight to enable some hitherto impossible scenario weakens by day. For security professionals and privacy conscious users, the good news is there is one major place to focus efforts, instead of multiple surprises hidden in a homebrew design a developer implemented without the benefit of public scrutiny a standard receives.

CP