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.

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).

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--