NNSquad - Network Neutrality Squad
[ NNSquad ] Risks in Mozilla's Proposed Firefox "Do Not Track" Header Thingy
Risks in Mozilla's Proposed Firefox "Do Not Track" Header Thingy
http://lauren.vortex.com/archive/000803.html
Greetings. Mozilla has proposed plans to implement a "Do Not Track"
flagging mechanism in their Firefox browser -- even though apparently
no companies have at this time promised to honor such anti-tracking
flags ( http://bit.ly/gqc6Oo [First Person Cookie] ).
Frankly, I continue to be singularly unimpressed by "Do Not Track"
concepts as currently being discussed, and continue to believe that
their ability to cause major collateral damage to the Internet
ecosystem of free Web services is being unwisely ignored or minimized
by many Do Not Track proponents (see: "FTC in Charge of Net Ads? --
and Opt-In vs. Opt" - http://bit.ly/ayfx90 [Lauren's Blog] ).
At an absolute minimum, necessary prerequisites for any Do Not Track
implementation methodology discussions should first be rigorous,
formal, and precise descriptions/dialogues regarding what Internet
"tracking" actually means in a wide range of situations and contexts.
Attempts to conflate this complex area into simplistic "Do Not Track"
signals for rapid implementation seem premature and ripe for Internet
users' "buyer's remorse" down the line.
Additionally, Mozilla's proposed use of HTTP "headers" for Do Not
Track purposes presents a number of fundamental technical problems.
In general, headers used in this manner represent what I'd call a
"non-acknowledged client-push signalling system." Sending out a new
"Do Not Track" header -- even beyond basic associated technical
requirements at the client and server ends -- and even if there's
agreement on how that header is defined -- tells you nothing about
what actually happens to that header after being sent by the client
browser. How does the user who sends such a header actually confirm
that they're "not being tracked" as a result? And how do they know
that continued tracking isn't caused by a technical issue that
prevented the header from ever being received and processed by the
destination server?
Perhaps the header line was "eaten" by an intermediate proxy server
(it's quite common for proxies not to pass along all headers). Or
maybe the header reached a server that simply hadn't been modified to
recognize it yet. Or did the header reach a server in some
jurisdiction (say, outside of the U.S.) that wouldn't even be
"required" to know about that new header? And so on.
You can't just send a Do Not Track header and expect meaningful
results. In practice, you end up having to build an entire
confirmation apparatus of some sort -- and even then it's likely to be
a mess. Without confirmation, you can send out whatever headers you
wish, but when you don't get the results you expect, what does that
mean? Who knows?
This all gets very complicated, very quickly.
Unfortunately, much of the current rush for Do Not Track appears to be
significantly driven at this stage largely by "political" agendas, and
politically-driven "quickly expedient" technologies are often the most
problematic of all.
--Lauren--
Lauren Weinstein (lauren@vortex.com)
http://www.vortex.com/lauren
Tel: +1 (818) 225-2800
Co-Founder, PFIR (People For Internet Responsibility): http://www.pfir.org
Founder, NNSquad (Network Neutrality Squad): http://www.nnsquad.org
Founder, GCTIP (Global Coalition for Transparent Internet Performance):
http://www.gctip.org
Founder, PRIVACY Forum: http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com
Twitter: https://twitter.com/laurenweinstein
Google Buzz: http://bit.ly/lauren-buzz