|Google, Safari, and a Clamor of Cookie Confusion|
February 18, 2012
A technological smoking gun is indeed present in this case. But it's not the gun being implied by confused headlines and the pronouncements of some commentators who appear to perhaps be out of their technical depths in this situation.
Thinking about it all these years later, I can't remember when I first ran across the term "cookie" in a computing sense. And offhand, the origins of this term as an "intermediate storage" element are somewhat hazy.
I do vividly recall that my first active entanglement with these babies was in the context of so-called "Magic Cookies" used by many early CRT data display terminals as a memory minimization technique -- to provide for character enhancement functions like blink, underline, bold, and so on. We Computer Science types have long been enamored of "magical" terminology - Magic Cookies, Magic Packets, Magic Words (e.g. "XYZZY" - "PLUGH"), and so on.
Even the "magic cookies" of CRTs were much maligned. Of course this wasn't really the cookies' fault. Memory was expensive and often minimal in these displays, and magic cookies actually used up one (or even more) spaces on the screen, making really clean layouts impossible. Display terminals that featured magic cookies were considered "terminally" brain dead by those of us in the know, and were typically assigned to the lowest ranking faculty, staff, and students. Some colorful disputes ensued.
Flash forward to the Web. The essentially "stateless" nature of basic HTTP transactions needed a mechanism to provided session-based coordination, and browser cookies stored on users' local computers quickly became the mechanism of choice to hold the intermediate data for this purpose.
As in the case of those magic cookies long ago, there is nothing inherently good or evil about Web cookies. They are simply local containers of data that can (subject to various rules) be written and read by Web sites.
But in the real world of the modern Web, the proper implementation of those "rules" by browsers and Web sites alike can become fiendishly complex.
OK, back to the current dramatic brouhaha over Google, Safari, cookies, and privacy. There's no way to deal with this accurately without getting somewhat technical, so please bear with me if you will.
Since the handling of browser cookies has long been complicated and controversial, all manner of methodologies to deal with them have emerged over the years.
At one time, I actively micromanaged virtually all of my browser cookies. But as Web systems became more intricate, such a detailed hands-on approach becomes decreasingly practical (these days I use browser extensions to maintain a relatively course control of cookies at the site level, but I would not recommend even this to most users).
One of the most common problems that Web users get themselves into is following simplistic advice about "blocking" cookies, and then becoming confused when they can no longer log into desired sites because the necessary session state cookies cannot be processed properly.
The proper handling of so-called "third-party cookies" by browsers and sites can be particularly challenging to implement. Such cookies are associated with domains other than that with which the user is primarily communicating at that moment.
Traditionally, browsers have accepted the reading and writing of third-party cookies by default, in some cases providing user controls for more fine-grained management of these cookies related to particular sites.
Third-party cookies have become controversial since they are sometimes viewed as being associated with "secretive" tracking practices. But there is nothing inherently wrong with third-party cookies. Like all browser cookies, it's what Web sites specifically do with them that matters, and especially with the rise of social sharing applications, third-party cookies can play important and utterly benign roles.
Now we reach that smoking gun of which I mentioned earlier.
Safari browser designers sometime back decided to diverge from common Web practice and block all third-party browser cookies by default.
The underlying rationales for this decision are not entirely clear and are a matter of some controversy. Even within the Safari developer groups themselves it's clear there was conflict about whether or not this actually was a useful, truly privacy-positive move.
But one thing quickly became clear. The default blocking would have the effect of breaking important functionalities on which many Web users depended.
WebKit is the common core implementation code used by Safari and various other browsers. Bug 35824 is at the heart of the entire Google/Safari cookie controversy.
Contrary to the assertions of some observers, Bug 35824 was not a leak involving third-party cookies being accepted inappropriately. It was not a loophole that needed to be closed.
In fact, it was exactly the opposite! Bug 35824 represented the realization that the existing WebKit implementation for third-party cookies, in conjunction with Safari's change to "no third-party cookies accepted by default" was too limiting, too closed, and needed to be loosened to restore key user functionalities.
The resolution of Bug 35824 involved doing just that, and the discussions associated with that Bug make for fascinating (and delightfully geeky) reading.
One particularly insightful quote from the associated dialogue:
- - -
"Alright, I'm regretting stepping into the morass that is third-party cookie blocking. The overarching problem is that third-party cookie blocking can't actually provide decent privacy benefits without breaking sites. We can machinate around the privacy / compatibility trade-off forever. Compatibility always has a stronger pull because you can see that XYZ works after you bolster compatibility whereas you don't see the privacy costs because they're harder to measure."
- - -
At the time, those discussions were most focused on problems that sites such as Facebook and Microsoft would have with the new Safari policy, before Bug 35824 was revolved. Google+ would not go public for more than another year.
But when Google+ did appear, Google quite appropriately used the provided mechanism of the 35824 bug fix, for key functionality related to Google+ on Safari browsers, in very much the same way intended for Microsoft, Facebook, and other sites.
It's at this juncture that the issue of unintended collateral effects comes into play.
As noted above, cookie handling can be very complex. Nowadays, traditional cookies have been joined by other (generally less well known) Web transactional local storage mechanisms, further complicating the picture.
The necessary loosening of Safari default third-party cookie controls associated with the 35824 bug fix even further convoluted the cookie handling process. This ultimately led to some cookies associated with Google's ad delivery network being mistakenly placed on some Safari users' browsers, in conflict with what those users might otherwise have expected from Safari's "no third-party cookies" default (keeping in mind that few Safari users would likely have had any inkling that there was already an exception to that seemingly declarative setting, via the 35824 fix).
The Google ad network cookies in question should not have been placed through the Safari browsers of users with that "third-party cookie blocking" setting. Those cookies were in error, and Google is in the process of removing them.
But those cookies did not contain personal information, nobody was harmed, nothing was damaged, and there is no indication that this event was purposeful subterfuge of any kind by Google.
There is an important lesson to be drawn from all this.
My gut feeling is that we've passed beyond the era where it made sense to concentrate on Internet privacy controls and issues mainly in terms of specific technologies as we've done in the past.
As noted above, cookies are neither good nor bad, neither intrinsically righteous nor evil. Cookies, like the other local storage mechanisms that have now been implemented, are merely tools. And as with other tools, how they are used is under the control of the entities who deploy these complex functionalities.
Ultimately, we expect Web sites to just work. It is unrealistic in the extreme to expect most users to understand and manage the underlying cookie and related systems of their browsers in detail. As new methodologies come online, this will only become ever more true.
What we really need to be concentrating on are the fundamental issues of trust and transparency.
If we as users feel confident that individual firms are doing their best to be transparent about their policies and are handling our data in responsible manners, then putting our trust (and data) in the hands of those firms is a solid bet.
Does this mean that mistakes won't be made and errors won't ever occur with the firms to whom we delegate these responsibilities?
Of course not. We're all merely humans, and true perfection is not within our current realm, nor is it likely ever to be.
But to assume that every error involving extraordinarily complicated software systems is evidence of evil intent is not only inaccurate and inappropriate, by to my way of thinking essentially perverse.
Unfortunately, the political environment in which we live today is replete with character assassinations and toxic "big lie" strategies. It is perhaps unfortunately unavoidable that such perverted approaches would seep into our considerations of highly technical topics as well. We must resist this.
When there are technical challenges we should meet them, when there are technical problems we should solve them. The intersection of technology with social policies is deep and becoming ever more entrenched with every passing day.
The accusatory rhetoric that has wrecked much of our political system cannot be allowed to substitute for reasoned and logical analysis of technical concerns, or the risks to society will be catastrophic.
Whether we're talking about browser cookies or nuclear weapons, the same underlying truth applies.
That's what I believe, anyway.