Re: Updated Server Response Section of TPE

Hi Roy, 

already in the introduction (5.1), the summary sounds like we have a 
fundamental disagreement on what DNT should do or be..

It says:
The Tracking Protection protocol is designed to be applicable regardless of 
the response from servers that receive the tracking preference expression, 
allowing conformance to be achieved without impacting the operational 
performance of site resources.

This means you assume that a browser can send DNT;1 into the wild and expect 
that to work. I doubt it will work or that anybody can assume anything by 
sending some token to someone. The browser can only be sure if in the 
corresponding response from the server received (e.g. together with the 
200OK message) there is some DNT ACK header. I don't want to teach a legal 
class here, but there is a fundamental difference between sending something 
and a matching message exchange. 

It all burns down to what we call a conforming implementation. A tool that 
blindly sends some DNT;0 or DNT;1 with every request and doesn't do anything 
else isn't good enough IMHO and will also be unable to express consent. I 
also fear that having such tools being conformant is calling for trouble. We 
will have some tools only sending DNT;0 with requests and other tools 
(extensions, local proxies and what have you) that will send DNT;1 
regardless. I don't want those to be conformant implementations. They will 
call themselves DNT and the term is not protected, but the W3C version 
already acquired some renown.

So the server MAY respond is not strong enough. Either it MUST respond (via 
the header) or it MUST respond to the first request or it MUST be bound via 
the semantics in the well-known location for all requests. Perhaps we agree 
and it is only a matter of wording.

Furthermore, there is wording missing that is important for the consent to 
become semantically possible. Namely that when sending DNT;1 and receiving 
t3, the browser can assume that the site does not honor DNT. (and start the 
blocking tools)

Again, the document currently reflects the tracking status as WKL only. I 
already objected to that. If you need a complete re-write of that section à 
la sauce Rigo, tell me and I will do it. If a user agent checks the tracking 
status at the well known URI and gets an error, the User Agent still has the 
header. I would even go so far to assert that a header is already in the 
response with the content. And only if there is no header, a UA should make 
the additional round trip to check that WKL. This spares one round trip. 
Aren't the browsers competing on speed anymore?

The header is not a supplement to the tracking status resource. The WKL and 
tracking status resource is an alternative to the header. 

The W3C site has over 50 000 resources in datespace with different ACL that 
will trigger different tracking feedback messages depending on the ACL. A 
WKL would mean that the entire site with tracking status has to be 
reproduced under the WKL. A header is simpler and cleaner. 

If you want to have more tracking status information in a well-known 
location, we may start to talk about reviving P3P. There are nice semantics 
that your tracking status could benefit from, e.g. who is responsible for 
the data processing (data controller), retention times and other useful 
information. But semantically, this is not responding anymore, this is 
announcing a policy. 

Roy, so if you disagree, I think we have to raise an issue so this is 
correctly tracked.

Best, 

Rigo








On Tuesday 22 May 2012 15:47:15 Matthias Schunter wrote:
> Hi Folks,
> 
> Roy has drafted an updated section 5 on server responses. It is posted at:
> 
> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#respon
> ding
> 
> Please review the update and comment to the mailing list.
> 
> 
> Regards,
> matthias

Received on Tuesday, 29 May 2012 20:25:24 UTC