Do-Not-Track and P3P: new privacy standard, weaker approach


[Full disclosure: The author was a participant in P3P standards effort and implementation in Internet Explorer.]

It could be the Internet equivalent of full moon, because someone is trying to introduce a privacy standard. After W3C threw in the towel on P3P, a very different proposal called Do-Not-Track, developed under the auspices of the same mighty standards body, is gathering momentum. Along the way it has stirred even more controversy than its predecessor, understandable in light of the higher stakes. The jury was out on advertising as a viable business when P3P was being debated. Its most vocal opponents were not exactly household names. (Case in point: several banner-ad networks were early participants in the standardization effort. Reminiscent of the old adage: best way to undermine a standard is to participate enthusiastically in its development committee.) Fast forward to today and there are many revenue models around delivering tailored content based on user interests.

There is overlap in the cast of characters as well. A late participant to P3P, MSFT is spearheading the push for DNT this time around. Latest version of Internet Explorer is configured to send DNT header by default, in another heavily-contested decision. Somewhat incongruously for such a bold strategic call, the option itself is buried under a check-box in Advanced settings, instead of the Privacy tab where one would normally expect to find it:

Advanced settings dialog, with DNT checkbox

Do-Not-Track setting

Depending on perspective, that speaks of expediency or deliberate design. As one commenter here pointed out, it is much easier to add a checkbox to the kitchen-sink of advanced settings, than to alter the layout of manually crafted privacy tab. For the conspiracy-minded, burying a setting there make it all that more difficult for users to override the default.

Elsewhere in the industry, confusion reigns. Chrome was missing in action until recently, Firefox twice tried to explain its stance on default settings. Industry groups are crying foul, painting doom-and-gloom scenarios about what DNT will do. Privacy advocates on the other hand fear DNT does not go far enough, predicting that it will be easily subverted and calling for more draconian measures. P3P redux? Not quite. The controversy around DNT may be obscuring stark differences from P3P.

Do-Not-Track is a unilateral declaration. The user indicates their desire to avoid tracking by adding a note to every request sent to web sites. Putting aside for a minute the endless debate over what constitutes “tracking” and what compliant websites are supposed to do in response to receiving the DNT header– issues acknowledged as unresolved in the specification itself: what happens next? How does the user determine if their request is honored and what is the response if the answer is no? This is not necessarily a question of intent: the developers may not have gotten around to implementing DNT or they may not even be aware of it. One can not fault sites for failing to keep up with the latest RFC fashion and standard-du-jour. Early versions of the protocol ignored this problem in favor a simple one-way communication, a monologue delivered by the user. Following the inevitable rule that every protocol acquires bloat through the standardization process,  latest revisions address that oversight. Now there are optional (read: not going to happen) HTTP response headers, as well as a mandatory site-wide tracking status resource (read: bare-minimum everyone is expected to implement) formatted in JSON.*

But implementations have not kept up. IE10 sends the header with determination, then remains oblivious on whether that gesture made any difference. First-party sites could signal their objection by showing users an error page, but this is not a realistic solution. Even that option is not available to embedded third-party content, where the only viable solution is returning an error. But since users interact with third-party content in the context of a different top-level website, the result is some other website that looks broken. The problem is worse when trying to distinguish between those who have not yet implemented the standard yet and those actively paying attention to DNT. In other words, even early-adopters embracing the standard get little more than bragging rights.

P3P had two crucial differences. First it is the website doing the talking. The protocol calls on sites to declare their data practices in machine readable format suitable for automatic evaluation, and places the onus on web browsers to alter their behavior in response to any discrepancy between stated policy and user expectation. This is how the specification is written; it does not leave any wiggle room for implementations to do it the other way around. More importantly P3P adds a measure of self-defense. If the privacy policy is considered unsatisfactory according to the user criteria, the web browser starts rejecting cookies or otherwise impairing tracking functionality.**

Consequently P3P is not a one-sided plea for privacy. Users are not shouting in the darkness, in hopes that the benevolent web site will grant their wish. Similarly sites are not being asked to modify their behavior based on some unilateral user decision. They are only asked to declare existing behavior. If a site chooses to not implement P3P, that is strictly their decision. Possibly some functionality will break. The breakage could be obvious or it could be subtle– as in the case of downgraded cookies for third-party advertising networks. Either way the outcome is made transparent to the user: a somewhat confusing eye-of-Sauron icon in the status bar indicates when cookie handling has been  impacted by P3p. Both sides can attempt to influence the result. User can decide the website has compelling value to merit an exception and lower her privacy settings. Or she may deem lack of P3P compliance unacceptable and click away to a more enlightened competitor.

If DNT makes no difference to the user experience– not even a simple thumbs up/down indicator– there is little intrinsic motivation to support the standard. That leaves one last resort for deployment: external regulatory pressure. Both P3P and DNT make implicit assumptions about a surrounding regulatory framework to keep actors honest. But the difference in approach also translates into different degrees of intervention required.

[Continued]

* Another difference from P3P is abandoning XML for JSON– angle brackets are out, curly braces are the latest fashion.
** Granted it is naïve to assume that that tracking can be stopped completely by dropping cookies. It was not even true in 2000, as one of my colleagues from IE6 team pointed out on his blog. Since then newer developments such as Flash and HTML5 only added to the number of ways to emulate cookies using existing browser functionality. But the concern that cookies may stop “working” provided sufficient impetus for P3P adoption.

3 thoughts on “Do-Not-Track and P3P: new privacy standard, weaker approach

  1. I agree with you that the lack of acknowledgement from the server is a big flaw in current DNT proposal. Did the server understand the DNT=1 flag? Did it honor the flag?

    If the server returned a DNT=ACK or some such signal, browsers would be able to detect when the acknowledgement is missing and display a message to the user (“This site does not currently honor DNT preference.”).

    If users really care about privacy (I’m not sure they do), then such messages would let them avoid (or complain about) sites that don’t respect their preferences. It seems a simple solution, I don’t know why that isn’t part of the draft standard.

    [As usual, these comments are mine; I do not speak for my employer.]

  2. The latest version of the standard does provide for an HTTP response header to indicate that signal:
    http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#tracking-status-value

    The catch is these are *optional* fields. Only compliance requirement is to publish a file at well-known location, leaving the onus on the web browser to fetch it. (Now which web browser wants to slow-down rendering further by doing a blocking GET on a policy file?)

    So there is no way to distinguish a site ignoring DNT from one that listened to user request, without doing this type of check each time.

  3. Thanks. This new draft seems a good improvement over the previous situation. I’ll read more details tonight.
    I see the problem with extra file, but that can be pipelined, cached, fetched after the first page is rendered, built into indexes of known domains, added to search engines, etc. Sites can now publish and advertise their DNT compliance and use that to attract customers.

    Although imperfect, this at least lets the browser determine if DNT is honored. Then the browser can present the user with information in some reasonable experience (warning, default block for paranoids, …).

    Now the onus is on users to vote with their clicks. This will demonstrate people’s preferences towards privacy.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s