Do-Not-Track [0] is a recent proposal by the FTC [1] to deal with the problem of users being “tracked” by advertisers. This consists of adding a new HTTP header[2] into page requests that indicates that the user is “opting out” of being “tracked”
The proposal is backed by a number of major players, including Mozilla [3] , the Electronic Frontier Foundation [4] , Wladimir Palant (the maintainer of of AdBlockPlus)[5] , and Giorgio Maone (the author of NoScript) [6].
Is this a good idea? Does it solve any existing problems?
One important factor to consider is that everyone has a different understanding of the concept of “tracking”. If a user has the header set but logs in to a service is there a difference? What if the user closes the browser in between sessions? Can the service remember who logged on last? Can a bank track a user’s visits for security purposes? What about a quiz website tracking participation to prevent cheating? And these are the simple questions. The definition of the word ‘tracking’ is not officially established.
Google claims it anonymizes IP addresses [7] but the “anonymization only involved clearing the last octet of the user’s IP address.[8] Is that considered tracking? Who decides? You? Google? The government?
Even if we came to a shared definition of what it means to “track”, how can one prove if tracking is done or not?
Let’s imagine that the US government enacts a law requiring websites to follow this header based on this elusive definition of “tracking”. What about servers outside the US? How would their activity be handled? What about a foreign user accessing a US based website? The reverse? What if different jurisdictions came to had two mutually exclusive definitions of “tracking”?
Furthermore, what if websites began to deny service to users that used the X-Do-Not-Track header? Browsers would be forced to remove the header in order to browse the web - effectively nullifying the header’s original purpose.
Arvind Narayanan [9] says that “Examining ad blocking allows us to predict how publishers, ... assuming DNT is implemented as a browser plug-in, ad blocking and DNT would be equivalent ... ad blocking would result in a far greater decline in revenue than merely preventing behavioral ads. We should therefore expect that DNT will be at least as well tolerated by websites as ad blocking.” This analysis assumes that the header will be in a plugin or optional setting. If every browser implements this header by default, as they should to attract more users, a much larger percentage of people will be opting out than with ad-blockers today.
What if the law disallowed differing service for those with or without the header? What would be the point? It would make sense to simply disallow “tracking” for all websites, which would make the header moot. Of course, this idea is subject to the same questions as asked above.
Instead of focusing on silly request-based ideas for websites, browser vendors should be working on fixing the privacy holes that have been already been found. Some examples include Firefox’s fix for the CSS history leak, Internet Explorer’s anti-tracking features [10][11] and related instances
What if browser vendors could consider idea of shipping their browsers with mini versions of ad-preventing software like AdblockPlus, NoScript[12] , and RequestPolicy[11] that blocked major third party advertisers such as doubleclick. Of course this could become a cat and mouse game - and it may not be a good idea at all - but it would be more effective than the do-not-track header. Other options include appeasing advertises with targeted user advertising and behavior analysis that doesn’t violate user privacy. For examples see the footnote [13]
Quite simply what we need for increased client side awareness of the privacy implications of various features and some form of control given to the users about what data the transmit across the Internet about themselves.
[0] http://donottrack.us/
[1] http://www.ftc.gov/os/2010/12/101201privacyreport.pdf
[2] Originally the header was “X-Behavioral-Ad-Opt-Out: 1 X-Do-Not-Track: 1” but the current version is now “X-DNT: 1” to save bandwidth
[3] https://wiki.mozilla.org/Privacy/Jan2011_DoNotTrack_FAQ
[4] https://www.eff.org/deeplinks/2011/01/mozilla-leads-the-way-on-do-not-track
[5] https://adblockplus.org/forum/viewtopic.php?t=6492
[6] http://hackademix.net/2010/12/28/x-do-not-track-support-in-noscript/
[7] http://searchengineland.com/anonymizing-googles-server-log-data-hows-it-going-15036
[8] http://news.cnet.com/8301-13739_3-10038963-46.html
[9] http://33bits.org/2010/09/20/do-not-track-explained/
[10] http://blogs.msdn.com/b/ie/archive/2010/12/07/ie9-and-privacy-introducing-tracking-protection-v8.aspx
[11] http://blogs.msdn.com/b/ie/archive/2011/01/25/update-effectively-protecting-consumers-from-online-tracking.aspx
[12] These particular addons “break” websites by default, but they can be configured in such a way to limit the damage they cause.
[13] See http://crypto.stanford.edu/adnostic/ Profiling and targeting take place in the browser. The ad network is unaware of the user’s interests
Thank you to JT very much for the sane editing and thoughts provided.
Sure, so let me get your point, flag to the company who tracks you that you do not want to be tracked and trust them their support it.
ReplyDeleteRight.
Will is this be the best security feature invented in the history of humanity?
If you make wildly improbable assumptions you can prove whatever you want.
ReplyDeleteNo browser is even remotely considering enabling DNT by default, and there are good reasons why this is simply impossible. More importantly, nobody is advocating for it, including DNT proponents.
Instead of focusing on silly request-based ideas for websites, browser vendors should be working on fixing the privacy holes that have been already been found
Good example of false dilemma. No reason not to do both.
No browser is even remotely considering enabling DNT by default, and there are good reasons why this is simply impossible.
ReplyDeleteI'll grant you this. This is not the mainstream viewpoint although I have seen people suggest enabling the header by default.
Good example of false dilemma. No reason not to do both.
This is true. However I question the efficacy of the header. What will using X-DNT accomplish that simply not transmitting said information accomplish?
Of course there is some information that one transmits in order to effectively use the service. In that case I fail to see how the header provides any meaningful difference to the users.
My original title was a bit stronger than I intended so I changed it. Until the meaning, verification, and enforcement of X-DNT is fleshed out I don't see any value in adding the header.
To be precise but short my claim is that: "At present the X-DNT headers provides no value to end users."
That said I could be wrong and I appreciate you commenting on my post.