Do-Not-Track: The Recipe for Frosting is Not the Wedding Cake

I laughed out loud when I read the following line in Harlan Yu’s post, “Some Technical Clarifications About Do Not Track“:

“[T]he Do Not Track header compels servers to cooperate, to proactively refrain from any attempts to track the user.”

(Harlan’s a pal, but I’m plain-spoken with friends just like everyone else, so here goes, buddy.)

To a policy person, that’s a jaw-dropping misstatement. An http header is a request. It has no coercive power whatsoever. (You can learn this for yourself: Take 30 minutes and write yourself a plug-in that charges ten cents to every site you visit. Your income will be negative 30 minutes of your time.)

Credit goes to the first commenter on his post who said, “What if they ignore the header? . . . Wouldn’t there also need to be legal penalties in place for violations, in order for this to work? (To encourage advertising companies to put in those lines of code.) Is this in the works?”

Of course there would be. That is the hard stuff. Just what behaviors amount to “tracking” anyway? It’s easy to say you don’t want to be tracked—hard to say what that is, especially given the fluidity of information flows and business models in the online environment. Once a definition is in place, might there be some tracking that consumers want, necessitating an exceptions system? Yes.

And what domains would be subject to the Do Not Track regulation after its years of development? The FTC’s jurisdiction is very broad in the United States (very narrow elsewhere), so every U.S. company with a web presence—large and small—would have to monitor the regulation’s development to determine whether they were going to be subject to the rules. Web-business would hold off on development to make sure they’re not building to an illegal business model. What if foreign countries write similar rules—but not identical. Pity the businesses trying to comply with multiple national Do Not Track regimes.

Coders find it really easy to trivialize coding.

On the server-side, adding code to detect the header is also a reasonably easy task—it takes just a few extra lines of code in most popular Web frameworks. It could take more substantial work to program how the server behaves when the header is “on,” but this work is often already necessary even in the absence of Do Not Track.

It’s easy, right? Except that people in every web-based business will have to understand what this means and how it might affect them. Just how broadly will server-side coding have to be implemented?

If you’re new to public policy, you’ve caught me overstating the scope of the regulation. Because we all know that it’s just going to be ad networks, right? Yeah, and the Social Security Number is only for administering the Social Security system. Have you ever seen Congress act without careful consideration? Have you ever seen it shrink the scope of a regulatory requirement? Come and stay awhile. You’ll see one but not the other.

Put all these issues aside, though. Let’s say you’ve taken the years it takes to get a rule in place, and you’ve got all the legitimate sites subject to the rule re-tooled and prepared to obey. Privacy is a little bit better prote—Wait! We just begged a key question: Which are the legitimate sites and which are not?

To solve that problem, you have to have some permanent institutionalized patrolling of the Internet—much of the information economy, actually—looking for business behavior that is inconsistent with fealty to the Do Not Track regulation. The FTC, or consumer groups and private attorneys general hunting legal fees, will go creating false identities and salting them into website log files hoping to get some tailored advertising. A-ha! Tracking!

But how will they really know it’s a product of tracking? It might make the most sense to give the FTC the power to subpoena data held by web sites. Much of it will be personally identifiable, but . . . oh, crap. We’ve just created a system where databases of information have to be handed over to the government to ensure that the information remains private…

This is a quick and slightly careless dash through the myriad issues that are involved in Do Not Track on the regulatory side, but perhaps it illustrates that the “technical” issues are the easy ones. The recipe for frosting is not the wedding cake.

I get what our tech-side friends are saying. There are lots of tracking technologies, and more to come in the future. They don’t want to fight a drawn-out war to protect people from receiving customized advertising. (Put aside whether that’s even a good idea.)

The war doesn’t end because you can write code to implement a signal in the http header. It shifts to a different venue. That venue—do you really need to be told?—is crawling with mercenary soldiers who work for the ones with the money. That is generally the business sector. If you push the problem on Washington, D.C., you’ll be even less satisfied than if you have to watch the market slowly discover and build the technologies that actually deliver privacy protection on the terms people want, and that do so by controlling information.

SHARE: 2 comments