RE: fyi: Fingerprinting risk

I agree it is a semantic discussion. I would favor making clear distinctions between controller, sameParty(including processors) and otherParty and changing the TPE text accordingly. Having a clean controller property has its merits. 

My text proposal for the other-party property was:

6.5.x Other-party Property

Since a user's experience on a given site might be composed of resources that are assembled from multiple domains, it might be useful for a site to distinguish those domains that are not subject to their own control (i.e., no information might be obtained via the controller property or the same-party property). An origin server MAY send a property named other-party with an array value containing a list of (sub)domain names that the origin server claims to include, to the extent they are referenced by the designated resource, and if all data collected via those references do not share the same data controller as the designated resource. 

The counter proposal from Shane was - in my view - an extension of this proposal, with additional requirements in terms of signaling back the browsers (blocking) behavior. Since we are close to a new text proposal, I think it is wise to take one step back and look at the definitions of the three properties controller, sameParty, and otherParty and ask ourselves whether the current text is fit for purpose.

Rob

-----Original message-----
From: Mike O'Neill
Sent: Saturday, May 6 2017, 10:02 am
To: Rob van Eijk; singer@apple.com
Cc: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org
Subject: RE: fyi: Fingerprinting risk

Same-party is defined in the TPE text as a list of domains (not persons) that “share the same data controller”, which must mean a set of domains managed by the same entity. If it is supposed to also cover data processors (acting for) for the same data controller we should amend the text. I suppose it could be “share the same data controllers” (plural), but then surely Google would have to be mentioned in the “controller” property in this case.

 
Here is the current text:

 
6.5.6 Same-party Property

 
Since a user's experience on a given site might be composed of resources that are assembled from multiple domains, it might be useful for a site to distinguish those domains that are subject to their own control (i.e., share the same data controller as the referring site). An origin server may send a property named same-party with an array value containing a list of domain names that the origin server claims are the same party, to the extent they are referenced by the designated resource, if all data collected via those references share the same data controller as the designated resource.

 
A user agent might use the same-party array, when provided, to inform or enable different behavior for references that are claimed to be same-party versus those for which no claim is made. For example, a user agent might choose to exclude, or perform additional pre-flight verification of, requests to other domains that have not been claimed as same-party by the referring site.

 
From: Rob van Eijk [mailto:rob@blaeu.com] 
Sent: 06 May 2017 08:11
To: Mike O'Neill <michael.oneill@baycloud.com>; singer@apple.com
Cc: 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; public-tracking@w3.org
Subject: RE: fyi: Fingerprinting risk

 




Google positions itself as a data processor for its analytics product. However, this does not come by default. The controller responsible for the cookie and the third-party tracking has the option to sign a processor agreement with Google in the GA-interface. To meet the status of processor, DPA's require controllers to take additional privacy friendly measures. For instance, the controller can restrict the use of analytics data for his own purposes and tell Google not to use the data for its own purposes. There are a few more actions a controller can take to minimize the impact on the privacy of the user, such as, making sure the script includes "ga('set', 'forceSSL', true);" and "ga('set', 'anonymizeIp', true);". Some DPA's have provided guidance, e.g., the writeup (in Dutch) here: https://www.autoriteitpersoonsgegevens.nl/sites/default/files/atoms/files/handleiding_privacyvriendelijk_instellen_google_analytics_0.pdf

I believe, when the controller has met the privacy friendly conditions that Google is offering today, www.google-analytics.com <http://www.google-analytics.com>  SHOULD go under SameParty. If the conditions have not been met, www.google-analytics.com <http://www.google-analytics.com>  MAY be listed under OtherParties or else it SHOULD be blocked by the browser.

Rob

 
-----Original message-----
From: Mike O'Neill
Sent: Saturday, May 6 2017, 8:27 am
To: singer@apple.com <mailto:singer@apple.com> ; Rob van Eijk
Cc: 'Matthias Schunter (Intel Corporation)'; public-tracking@w3.org <mailto:public-tracking@w3.org> 
Subject: RE: fyi: Fingerprinting risk




Script can always be loaded into a browsing context from another origin, as can an image or other resource (not html though). Once it is loaded it can execute any API, and so it can call the Exception API.

But the document origin and the script origin will be the origin of the browsing context it is running in, not the origin it was loaded from.  It does not matter at all to the operation of the script which domain the it was loaded from.

This obvious example is Google Analytics. A top-level context example.com includes a script tag with a src attribute "//www.google-analytics.com/analytics.js <http://www.google-analytics.com/analytics.js> ". The script analytics.js is executed in the example.com origin.

The script dynamically creates an image whose src attribute also points to google-analytics.com (with a complicated path component that incorporates the UID from a cookie stored in example.com), which results in an embedded tracking request to be set to the www.google-analytics.com <http://www.google-analytics.com>  domain. 

The controller responsible for the cookie and the third-party tracking is the one for example.com. They might be unaware of what is going on, but their action of loading the script resource initiated it.




-----Original Message-----
From: singer@apple.com <mailto:singer@apple.com>  [mailto:singer@apple.com <mailto:singer@apple.com> ] 
Sent: 05 May 2017 22:29
To: Rob van Eijk <rob@blaeu.com <mailto:rob@blaeu.com> >
Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> >; public-tracking@w3.org <mailto:public-tracking@w3.org>  (public-tracking@w3.org <mailto:public-tracking@w3.org> ) <public-tracking@w3.org <mailto:public-tracking@w3.org> >
Subject: Re: fyi: Fingerprinting risk


> On May 5, 2017, at 10:41 , Rob van Eijk <rob@blaeu.com <mailto:rob@blaeu.com> > wrote:
> 
> 
> I understand that when a user is visiting a site, site-wide consent (initiated by the publisher) is Exceptions are all-or-nothing, based on the current TPE text (i.e., site-wide exception).. 
> 
> Two questions come to my mind when I turn the perspective to the 3rd parties. 
> - If there any third parties left not listed in OtherParties of SameParty that do not have OOBC consent and are not being blocked by the browser? 
> - If so, these 3rd parties could ask a user-granted exception through the API and he exception would only apply to that specific 3rd party, right? (i.e., site-specific user granted exception)

I think any site from which scripts are pulled can then ask for exception; it doesn’t have to be top-level. So if the top-level pulls in scripts etc. from site B, site B can run a script that asks for an exception for it.

I don’t think DNT has opened the can of worms of blocking, and I’m not sure I am ready to deal with all those worms just yet

> 
> Rob 
> 
> -----Original message-----
> From: David Singer
> Sent: Friday, May 5 2017, 7:17 pm
> To: Matthias Schunter (Intel Corporation)
> Cc: public-tracking@w3.org <mailto:public-tracking@w3.org>  (public-tracking@w3.org <mailto:public-tracking@w3.org> )
> Subject: Re: fyi: Fingerprinting risk
> 
> 
> > On May 5, 2017, at 0:43 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> > wrote:
> > 
> > Hi Folks,
> > 
> > I would like to elaborate why I changed my mind and why I now believe
> > that the fingerprinting risk has been mitigated ;-)
> > 
> > MY PAST MISUNDERSTANDING
> > - I assumed that users can do fine-grained choosing what subset of an
> > exception to accept and what to block
> > - The subset of blacklisted domains could be fairly individual
> > - Reporting back the list of blocked domains (the intersection between
> > the used third parties and the blacklist of a user) would be very
> > individual too
> > - As a consequence, reporting back this list would identify individual users
> > 
> > MY CURRENT THINKING
> > - Exceptions are all-or-nothing and sites may publish a list of known
> >  third parties
> > - None of the domains listed shall be blocked
> 
> The DNT spec. is silent about blocking. What it talks about is what headers you send and what they mean, and indeed exceptions are granted or denied as units. 
> 
> > - All the domains not listed shall be blocked and returned
> > - The list of domains that are blocked almost only depend on the
> >  site (i.e. what stuff it is including) and not on user specifics.
> > - As a consequence, the list of blocked sites should not allow
> >  identifying users.
> > 
> > [The only exception could be cases where the unknown sites loaded depend
> > on the user; e.g. an ad auction that pulls in unknown sites based on

> > user cookies. I hope that those are rare corner cases.]
> > 
> > Regards,
> > matthias
> > 
> > 
> > 
> 
> Dave Singer
> 
> singer@mac.com <mailto:singer@mac.com> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.