RE: tracking-ISSUE-183 (Tk E ): Additional Tk header status value for EU [Tracking Preference Expression (DNT)]

Hi Roy,

My understanding of the difference between 1st party and 3rd party is that
if I visit a site, by clicking on a link, one of my favourites or typing in
a Uri, the address-bar will show the Uri, the document origin will be the
domain subcomponent of that Uri, and that will be the 1st party domain. If,
in the course of rendering the HTML but without any further input from me,
further elements such as images, iframes etc. are accessed by my browser and
these cause requests to be sent to resources where the domain subcomponent
is different to the first party domain, these are 3rd party requests. These
are handled  in a different way in the TPC because they enable gathering of
user behaviour across sites.

This interpretation is also implicit in the exception API.

I agree that I could click on a link that purports to be on the same site,
but in fact is not. We should handle that case with text that requires
first-party sites that do that (create anchor tags and the like that take
users to foreign sites without explanatory text) ensure that the Uris always
point to resources that are designed to operate solely in a 3rd party
context.

In the case that link clicking is simulated by script it should be
reasonably easy for a user-agent to determine if a request has been caused
by user input. I know that Safari was fixed to make sure 3rd party cookies
are still blocked if a POST request is not the result of user interaction,
so this area has received attention recently.

If it is not possible for user-agents to determine if a link is 1st or 3rd
party in the sense used above we should remove the differentiation from the
spec. because bad actors can simply say they have out-of-band reasons to act
as 1st parties, or that they have a bug and didn't mean it.

Mike


 

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 23 October 2012 20:24
To: Mike O'Neill
Cc: 'Nicholas Doty'; public-tracking@w3.org
Subject: Re: tracking-ISSUE-183 (Tk E ): Additional Tk header status value
for EU [Tracking Preference Expression (DNT)]

On Oct 23, 2012, at 3:15 AM, Mike O'Neill wrote:

> The point about particular resource URIs changing from 3rd to 1st 
> party context is one of the reasons for the change I suggested in 
> issue-182. The user-agent has the party information at hand when it 
> sends out a request, and it would be simple for it to communicate this 
> to the server in the DNT header.

No, it does not.  The fact is that neither the browser nor the server knows
what requests are first party and what requests are third party.
Just clicking on a link doesn't make it the first party -- the identifier
would have to be compared to the contextual user information (the
information that gave the user the idea that they wanted to click on that
link).

In theory, the only way we could mechanically distinguish between first and
third party references would be to change the URIs (not going to happen) or
add additional metadata to the mark-up to indicate which is which; in
practice, we already know that authors won't correctly mark-up such links,
and I suspect TLR would be somewhat upset if I started redefining HTML here.

Of course, this has no impact on enforcement of the standard.
The people building Web sites know which links are to third parties, even if
they don't have a special mark-up.
Regulators are fully capable of distinguishing between where they intend to
visit and other entities that might be performing data collection -- a
simple browser extension or protocol stream capture will reveal all they
need to know, and is easily packaged as a tool.

> For example the handler associated with a social widget will normally 
> receive a request indicating 3rd party context usage ( DNT: 1) and the 
> handler will return Tk3. If a user clicks on it a request will be sent 
> out with the f qualifier ( DNT: 1f)  and the handler can return a Tk1 
> response if it now conforms to 1st party rules.
> 
> In the DNT = 0 case the exception API will have been called. In a 3rd 
> party context the DNT header would now be DNT: 0t=toplevel.com 
> indicating the document origin of the top level page, which is also 
> the origin host which initiated the exception. This can be used to 
> prove compliance (by retaining logs in the DNT:0 case) or to debug script
errors on the top level site.

HTTP already has Referer header fields.

....Roy

Received on Tuesday, 23 October 2012 22:41:06 UTC