RE: Housekeeping: Closing ISSUE-140 (concrete/explicit list of exceptions)

Hi Mike,

The Refer header is optional and someone concerned about tracking and privacy may well disable it.  Adding the information back in the DNT header might be a concern.  The server could certainly leak the information to the third party in other ways such as in the resource URL etc, but if it was respecting DNT then perhaps it should not.   You might consider the consequences of a user disabling the first party in the DNT header, or spoofing a first party.  A user might even spoof a first party in the DNT header to try and make a first party act as a third party - which might actually be a nice option as it would overcome the first party exceptions!

Including the first party in the DNT header may conflict with the requirements on a first party.  A first party is not permitted to share data with a third party that the third party would otherwise not know, and since the Referer is optional the third party would in general not know the first party.  Surely the DNT spec. should be setting an example and not violating its own standards.

cheers
Fred

From: michael.oneill@baycloud.com
To: fredandw@live.com
CC: public-tracking@w3.org
Date: Tue, 9 Oct 2012 09:10:43 +0100
Subject: RE: Housekeeping: Closing ISSUE-140 (concrete/explicit list of  exceptions)

Fred, Its only the hostname part which is already included in the referrer header, so no extra state is leaked. The only extra piece of information sent is when the top level is http and the 3rd party is https (or vice versa), so hard to see how that could be a fingerprinting risk. The ability to quickly determine 3rd party from 1st party contexts outweighs that. Mike From: Fred Andrews [mailto:fredandw@live.com] 
Sent: 08 October 2012 23:57
To: Mike O'Neill; 'Adrian Bateman'; 'Matthias Schunter (Intel Corporation)'; 'Jonathan Mayer'
Cc: public-tracking@w3.org
Subject: RE: Housekeeping: Closing ISSUE-140 (concrete/explicit list of exceptions) 
The Referer header already leaks private UA state, so the last thing we need is to leak more state out the DNT header.

> From: michael.oneill@baycloud.com
> To: adrianba@microsoft.com; mts-std@schunter.org; jmayer@stanford.edu
> CC: public-tracking@w3.org
> Date: Mon, 8 Oct 2012 18:30:24 +0100
> Subject: RE: Housekeeping: Closing ISSUE-140 (concrete/explicit list of exceptions)
> 
> I agree sites should be responsible for the exception UI and making the explicit 3rd party list optional could get us an early implementation. But it ([explicit, explicit]) should not be removed from the spec because it lets site UIs give better choice to users and some user-agents or extensions could still implement it.
> 
> Also, I think the "top level hostname" should be included in the request header i.e.
> 
> DNT: X;firstpartydomain.com; other qualifiers
> Where X is 1 or 0
> 
> This gives 3rd parties getting DNT:0 the ability to show (from retained logs) which 1st party executed the exception API, helping solve the problem Ed Felten pointed out in the breakout (this was when 1st parties executed the exception API without getting user consent and so 3rd parties receiving incorrect DNT:0 indications). By retaining logs they can show they were legally acting at the behest of the 1st party. The referer(sic) header cannot do it because it is not there for a https request (if it points to a non https site).
> 
> This header extension also gives server request handlers the ability to determine in-line whether they are acting as 1st or 3rd parties in both the 0 and 1 cases. They only need to test if the domain name in the header is different from the request host. 
> 
> When we have an issue for the new API I will suggest the text for this.
> 
> Mike
> 
> 
> -----Original Message-----
> From: Adrian Bateman [mailto:adrianba@microsoft.com] 
> Sent: 08 October 2012 14:35
> To: Matthias Schunter (Intel Corporation); Jonathan Mayer
> Cc: public-tracking@w3.org
> Subject: RE: Housekeeping: Closing ISSUE-140 (concrete/explicit list of exceptions)
> 
> On Monday, October 8, 2012 12:33 AM, Matthias Schunter wrote:
> > in the meantime, there is a revised proposal by the browsers on the table.
> > Basic ideas:
> > - Unchanged: 3 types of exceptions: site-wide, web-wide, and explict 
> > lists
> > - New: Sites are responsible for UI and for determining exceptions
> > - New: Browsers are free to validate/adjust exceptions based on user 
> > preferences
> > - New: No atomicity requirement anymore
> > - New: We added a query API where a site can validate whether its "essential"
> > exceptions are still present
> > in order to double-check that it is still working as intended.
> > 
> > Some advantages (from my personal perspective) are:
> > - Sites can provide a consistent experience
> > - Browsers can now freely manage preferences as determined by their 
> > users
> > - Sites can store a broad range of exceptions ("these are my 30 third 
> > parties" while later querying a subset "I need these 10 to work").
> > 
> > We have an action pending to elaborate this new proposal (AFAIR on Ian 
> > Fette). Feel free to comment once we obtain text documenting it in 
> > more detail.
> 
> My exception API proposal retained the explicit list option from the current spec because a) I wanted to minimise differences to allow people to more easily compare; and b) because some people I spoke to asked for this remain included.
> 
> However, it remains an optional feature (user agents may ignore the arrayOfSites
> argument) and, as I said based on the discussion at the F2F, I don't believe it is workable.
> 
> I think it adds unnecessary complexity to user agents were they to implement it, adds unfeasible complexity to sites trying to maintain the exception list in the face of dynamic relationships with third parties, and damages users'
> ability to form a mental model of what DNT does for them.
> 
> My preference would be to remove this from the spec for now and keep the API simple until we have more implementation experience. In general, I'd rather satisfy the 80% case now and come back and refine in future. I think this is something that could be added as a new feature later. At the very least, I'd recommend this feature be marked "at risk" for CR [1].
> 
> Cheers,
> 
> Adrian.
> 
> [1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
> 
>