W3C home > Mailing lists > Public > public-tracking@w3.org > June 2012

RE: The Rubber meets the Road - DNT compliance code

From: Kevin Smith <kevsmith@adobe.com>
Date: Wed, 13 Jun 2012 14:55:12 -0700
To: Peter Cranstone <peter.cranstone@gmail.com>, "ifette@google.com" <ifette@google.com>
CC: W3 Tracking <public-tracking@w3.org>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF30AEE4ED636@nambx07.corp.adobe.com>
No, you alert the user that you do not support the DNT setting from their browser and recommend that they change browsers if they would like to view your site in a DNT supported fashion.  I still get ‘supported browser’ messages all the time.  It’s a concept nearly as old as the web.

Kevin Smith  |  Engineering Manager  |  Adobe  |  385.221.1288 |  kevsmith@adobe.com

From: Peter Cranstone [mailto:peter.cranstone@gmail.com]
Sent: Wednesday, June 13, 2012 9:35 AM
To: ifette@google.com
Cc: W3 Tracking
Subject: Re: The Rubber meets the Road - DNT compliance code

Ian,

It's the why that's important.

So riddle me this. You're a DNT compliant server. If you see the DNT flag set to 1 on the inbound request you honor it. However if all of a sudden you see MSIE 10 UA's what do you do? Reject it because you don't like the fact that MSIE set is as the default?

You see – Microsoft has won the war. If you say you honor it, then you MUST accept their header. And if you don't honor DNT then it doesn't matter. The spec just got played.


Peter
___________________________________
Peter J. Cranstone
720.663.1752

From: "Ian Fette (イアンフェッティ)" <ifette@google.com<mailto:ifette@google.com>>
Reply-To: <ifette@google.com<mailto:ifette@google.com>>
Date: Wednesday, June 13, 2012 9:30 AM
To: Peter Cranstone <peter.cranstone@gmail.com<mailto:peter.cranstone@gmail.com>>
Cc: W3 Tracking <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: The Rubber meets the Road - DNT compliance code

Peter, all of DNT requires resources.

I don't get where you say there are legal consequences. If you tell the user "I'm not honoring your DNT request because <X>" and you're clear about your practices then you're not breaking any promises.
On Wed, Jun 13, 2012 at 8:28 AM, Peter Cranstone <peter.cranstone@gmail.com<mailto:peter.cranstone@gmail.com>> wrote:
Ian,

This is a case of win the battle on the forum but lose the war in the real world. It doesn't matter if it's neither hard or complex. The point is that it has to be done, tested and then updated and maintained. That requires resources – not something that everyone can afford to do.

Secondly, lets flog the dead horse one more time on "who set the DNT flag". If I have to write code that cannot guarantee 100% accuracy when it comes to this privacy setting AND there are legal consequences of me getting said code wrong (i.e. fines or pissed off customers) then I'm not going to do it.

We all know that per the spec that MSIE is not compliant because it sets the flag by default. But what admin in his right mind is going to reject it? If the server is DNT compliant then there is NO downside to MSIE setting the default.

We're back to stupid browser wars again and pissing off the customer. Not a good thing.



Peter
___________________________________
Peter J. Cranstone
720.663.1752<tel:720.663.1752>

From: "Ian Fette (イアンフェッティ)" <ifette@google.com<mailto:ifette@google.com>>
Reply-To: <ifette@google.com<mailto:ifette@google.com>>
Date: Wednesday, June 13, 2012 9:22 AM
To: Peter Cranstone <peter.cranstone@gmail.com<mailto:peter.cranstone@gmail.com>>
Cc: W3 Tracking <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: The Rubber meets the Road - DNT compliance code

Many websites already do this -- "serve this JS to this user agent". It is neither complex nor hard.
On Wed, Jun 13, 2012 at 7:44 AM, Peter Cranstone <peter.cranstone@gmail.com<mailto:peter.cranstone@gmail.com>> wrote:
All,

There's a lot of questions around a non-compliant UA sending a DNT header. There's still no definition on the forum or the spec on what constitutes a non compliant UA, or even who is going to maintain a "blacklist" of those non-compliant UA's. Finally there's no description of a message that should be sent back to the consumer indicating that he's using a non-compliant UA.

So I'm posting a link today of what something might look like running on a server. The reason this is in PHP is because there are lot of servers (in the 10's of millions) that cannot suddenly start adding server side modules that do the detection. So it will all have to be done via a script.

Think about this for a moment. In the real world server side admins are going to have to add code to EVERY CGI script to do this. The performance hit is going to be HUGE.

Here's the link: http://www.5o9mm.com/mod_dnt_test_1.php


We've blacklisted the following browsers:

HTTP_DNT_BLACKLISTED_USER_AGENT_1 = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0)
HTTP_DNT_BLACKLISTED_USER_AGENT_2 = Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
HTTP_DNT_BLACKLISTED_USER_AGENT_3 = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0)
HTTP_DNT_BLACKLISTED_USER_AGENT_4 = Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
HTTP_DNT_BLACKLISTED_USER_AGENT_5 = Mozilla/5.0 (Windows NT 6.0; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

So every time someone hits the Web site we have to run a check. The request time for this check on our server is:

REQUEST_TIME = 1339597469

For that single page. Now multiply that by every page on your Web site that is scripted. Ouch.

Now here's where it gets really interesting. Let's say that I'm on the blacklist. What does the server do? By rights it should abort the entire request and send a 400 invalid request response back to the user.

So what the heck does the user do now?

If this spec is going to be Trusted and used it has to work in the real world which is NOT 100% technical. They turn it on (or have it turned on for them) and they expect magic. They don't expect to be told that there browser is non-compliant and they can either go get another one or get tracked.




Peter
___________________________________
Peter J. Cranstone
720.663.1752<tel:720.663.1752>


Received on Wednesday, 13 June 2012 21:55:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:30 UTC