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