The Folly of Detecting Tracking from Cookies

Hi, Bil Corry here:

Earlier this year, Andy Steingruebl and I wrote a position paper on Do-Not-Track that criticized the push of a technology solution that did not have a corresponding comprehensive public policy, a public policy that contained input from all stakeholders. Our position is that an early push with Do-Not-Track has not properly define “tracking”, nor does it provide proper guidance for legitimate business use-cases.

To that last point, there has been two research projects that purport to show how user privacy is being violated, both of which rely on observing the behavior of the “tracking” websites to validate their claim.

Jonathan Mayer’s  “Tracking the Trackers” findings include:

• Half of the NAI members we tested did not remove their tracking cookies after opting out.
• At least eight NAI members promise to stop tracking after opting out, but nonetheless leave tracking cookies in place.

Ashkan Soltani’s  “Respawn Redux” findings include:

• In our follow up study, we found that Hulu was still respawning deleted user cookies using homegrown Flash and Javascript code present on the Hulu.com site. Additionally, Hulu, Spotify, and many others were also respawning using code provided by analytics firm KISSmetrics.

The problem with both studies above is that they conflate cookies with tracking.  One cannot determine if tracking is occurring by observing cookies – let’s look at a few examples:

1. Example: user sends the Do-Not-Track (DNT) header, the NAI member does not remove their “tracking” cookie.
   • The NAI member may have server-side logic that detects the DNT header and does not record (track) any information related to this user.  That would allow continued tracking in the future should the user turn off the DNT header while preserving the user's choice.
   • If data was collected prior to the DNT header, does the DNT header mean, “erase everything you already have about the user” and/or “do not use anything you already know about the user”?  What if the data collector provides an alternative mechanism to view and remove data, such as BlueKai’s Registry?  This area is very unclear.

2. Example: server detects their cookie has been removed and respawns it.

   • If the cookie being respawned was the opt-out cookie, would there be a privacy concern?  Cookie respawning can be used as a feature for users that erase all cookies, yet have asked the website to remember them.  Or to prevent fraud.  Or to prevent multiple views of the same ad.  One can argue that there should be a way to remove the respawning, but respawning in and of itself does not necessarily mean tracking is occurring.
   • The removal of a cookie does not necessarily represent user choice to not be tracked.  Cookie storage is finite in all browsers; cookies are removed according to a Least-Recently-Used (LRU) policy.  In addition, it’s possible for an attacker to force out all cookies by creating numerous bogus cookies (cookie eviction).

3. Example: servers collect tracking information based on email address and share it via a backend process.

   • The user will see no indication that they are being tracked and profiled.  There isn’t any mechanism being used to uniquely track the user on the browser side, instead their user profile with their email address is used to track them.  The user would have to rely on the website to honor the DNT header, there isn’t a technology solution to this scenario.

From the above examples, it is clear that it is impossible to determine tracking of users by viewing website behavior.  The only way to know if tracking is occurring is to view the behavior on the server-side.  Until studies actually account for server-side behavior, they are merely speculating as to whether tracking is occurring.

A comprehensive public policy is needed to define tracking and to define the obligations of providers when presented with Do-Not-Track and/or other privacy mechanisms.