Google, Safari, and a Clamor of Cookie Confusion http://lauren.vortex.com/archive/000937.html
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
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
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
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
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
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
Now, please permit me to introduce you to WebKit Bugzilla Bug 35824:
March 2010 ( http://j.mp/zwtDhL
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.
-- Lauren --