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

Hi Fred.

 

Yes, point taken about the ability to remove the referrer header. 

 

How about in the DNT:1 case putting in a qualifier, say 1p, when the
user-agent is sending a request to a 1st party, absent otherwise. So if a
request handler gets DNT: 1 with no 1p  qualifier it must assume no
tracking, and no sharing otherwise. Without this when a user-agent stripped
the Referer header a server would just assume first party and track away.

 

In the DNT:0 the user-agent still sends the top level hostname as in my
suggestion so 3rd parties can retain logs to prove compliance. As this is
DNT: 0 there is no data leakage without user agreement.

 

BTW I agree with you ( & Alan) that there should be no difference (between
1p & 3ps when DNT is set) but that consensus was reached a while ago and it
would be hard to change it now.

 

 

Mike

 

From: Fred Andrews [mailto:fredandw@live.com] 
Sent: 09 October 2012 11:28
To: Mike O'Neill
Cc: public-tracking@w3.org
Subject: 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
> 
>