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