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

Re: The Rubber meets the Road - DNT compliance code

From: Peter Cranstone <peter.cranstone@gmail.com>
Date: Wed, 13 Jun 2012 15:59:17 -0600
To: Kevin Smith <kevsmith@adobe.com>, "ifette@google.com" <ifette@google.com>
CC: W3 Tracking <public-tracking@w3.org>
Message-ID: <CBFE68A0.32AB%peter.cranstone@gmail.com>
Then you're not complying with the spec to honor a DNT header if your server
supports it.

The spec does NOT distinguish between a default setting made by the OEM and
a setting made by the user. Ergo you cannot distinguish either case on the
server. There should be no case where a browser that supports DNT is ever
rejected because you accused the OEM of making a setting vs. the user.

It will be a PR nightmare. Can you imagine the user saying – heck the Web
site rejected me because I was asking for privacy and it doesn't like the
browser I'm using. Yep, I can just see all the Tier 1 Web sites adopting
that approach.


Peter
___________________________________
Peter J. Cranstone
720.663.1752


From:  Kevin Smith <kevsmith@adobe.com>
Date:  Wednesday, June 13, 2012 3:55 PM
To:  Peter Cranstone <peter.cranstone@gmail.com>, "ifette@google.com"
<ifette@google.com>
Cc:  W3 Tracking <public-tracking@w3.org>
Subject:  RE: The Rubber meets the Road - DNT compliance code

> 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>
> Reply-To: <ifette@google.com>
> Date: Wednesday, June 13, 2012 9:30 AM
> To: Peter Cranstone <peter.cranstone@gmail.com>
> Cc: W3 Tracking <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>
>> 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>
>> Reply-To: <ifette@google.com>
>> Date: Wednesday, June 13, 2012 9:22 AM
>> To: Peter Cranstone <peter.cranstone@gmail.com>
>> Cc: W3 Tracking <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>
>>> 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:59:56 UTC

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