Re: Updated Server Response Section of TPE

On May 29, 2012, at 1:24 PM, Rigo Wenning wrote:

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

No, it doesn't.  It means that the response has no impact whatsoever
on whether DNT:1 works or not.

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

One has nothing to do with the other.  Messages are not a contract,
particularly when the client is providing nothing of value to the
server.  Expressions are not an agreement.

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

That's not relevant.  The paragraph says what is true of the tracking
preference expression -- you don't need an answer to know the expression.
Furthermore, it says "allowing conformance to be achieved", not
"is conformant".  The fact that my car's engine allows my car to reach
speeds of 120 mph does not imply that I drive that fast all the time,
nor does it imply that the car can do so without wheels and a level road.

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

It can be bound by any number of things, including regional law or
a privacy policy.

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

That's not what t3 means.  It means the site does perform tracking
some of the time, does conform to DNT, and is acting as a third party.

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

You did not provide any technical rationale for your objection.

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

I disagree.

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

No, in all respects.  I know how the W3C site works.  There are only
two policies---public and ACL---and they can be wrapped into one
tracking policy if we define authentication as overriding DNT.

Even if there were 50,000 different tracking policies in some imaginary
site, that site only needs to respond with the worst case. If it wishes
to respond distinctly, for example to implement a federated mechanism
for user control over tracking data, then it would obviously implement
that as a dynamic resource using a database.  Under no circumstances
is the well-known address more complex than a site needs it to be.

Most importantly, the resource only needs to handle requests by clients
performing active verification, which means the performance impact on
well-known locations is limited to those clients that want them and
not in the critical path, unless the client chooses to make that the
critical path.  Plus, the resource is itself part of the Web.

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

What is the issue?  If you think the specification doesn't reflect
a two-party contract between client and server, then I'll agree
with you and point out that it never will.  Our requirements do
not include that, nor am I going to entertain legal theories on
messaging exchanges when the user never sees the message (nor has
any hope of understanding it even if they did see it).

DNT is enforced by consistency with user expectations.  In Europe
and a few other states, those expectations are coded as law and
the services require permission to do tracking -- the DNT response
is irrelevant.  In the US, enforcement is tied to human-readable
representations made by the service and applicable best practices
for privacy (determined by context) -- the DNT response is irrelevant.
I believe other regions apply policies between those two extremes.
In all cases, the DNT response serves only to tell people how the
server intends to behave, which is good enough for the validation
scenarios that were requested as part of the initial design
discussions.  Actual conformance is determined by observing the
service behavior over time or via direct subpoena.

Under no circumstances are users protected by a few bytes sent in
header fields via HTTP.  That isn't how network protocols work. 

....Roy

Received on Wednesday, 30 May 2012 01:23:47 UTC