RE: fyi: Fingerprinting risk

Shane, 

 

That does not make sense.

 

There are only two API calls for arranging that embedded subresources get DNT:0

 

 

1)               storeWebWideTrackingException

Script in a top-level browsing context executes this to specify that its own domain (or some or all subdomains of it) will receive DNT:0 whenever the browser sends HTTP requests to them (i.e. anywhere on the web – so Web-Wide)

2)               storeSiteSpecificTrackingException

Script in a browsing-context (not necessarily the top-level one) specifies that it and some or all of its embedded subresources  will receive DNT:0 whenever the domain of the document origin of the original callee is the current parent context ( i.e so it only applies to that site – thus Site-Specific)

 

               What we call “site-wide” consent it the particular form of a Site-Specific tracking exception where the arrayOfDomainStrings is not supplied (or is null). The arrayOfDomainStrings is an array of strings representing the domains of particular embedded resources. If it is not supplied it this is taken to mean that all the subresources will receive DNT:0

 

When you give a subresource a Site-Specific Exception it only applies to that site (the site whose browsing context was active when the call was made). You cannot register Web-Wide consent with it, whether it was Site-Wide (which is also Site-Specific) or not.

 

Mike

 

From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 08 May 2017 19:09
To: Mike O'Neill <michael.oneill@baycloud.com>; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; 'David Singer' <singer@apple.com>; 'Rob van Eijk' <rob@blaeu.com>
Cc: public-tracking@w3.org
Subject: Re: fyi: Fingerprinting risk

 

Mike,

 

Incorrect.  Any 3rd party that arrives to a 1st party in the Domain array should receive DNT:0 under a Site-Wide Exception.  The goal is not to register those domains for a Web-Wide Exception so they are not listed in the array and only receive DNT:0 when they appear under a domain in the 1st party Domain array.  If you listed all 3rd party domains under the 1st party domain array it would be the same as granting them web-wide exceptions which is not the goal in this case.

 

- Shane

 

Shane Wiley
VP, Privacy
Yahoo

 

  _____  

From: Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >
To: 'Shane Wiley' <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com> >; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >; 'David Singer' <singer@apple.com <mailto:singer@apple.com> >; 'Rob van Eijk' <rob@blaeu.com <mailto:rob@blaeu.com> > 
Cc: public-tracking@w3.org <mailto:public-tracking@w3.org> 
Sent: Monday, May 8, 2017 10:38 AM
Subject: RE: fyi: Fingerprinting risk

 

No, the arrayOfDomainStrings parameter is for when you want to register site-specific consent for any set of embedded subresources (so they get DNT:0). Sure, you would probably also put yimg.net etc. in there.  

 

You would probably also put them into the same-party array because they are domains managed by the same data controller. BTW it would have been sensible to incorporate the same-party set into arrayOfDomainStrings automatically.

 

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

 

Mike,

 

The arrayOfDomainStrings is meant to define the dimensions of the 1st party - not to include 3rd parties.  For example, Yahoo.com would add Flickr.com and yimg.net to that list.

 

- Shane

 

Shane Wiley
VP, Privacy
Yahoo

 

  _____  

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

 

The site-specific call already has the option for a restricted list to receive DNT:0 via the arrayOfDomainStrings argument, otherParties would not add anything if it only affected DNT. The reporting API is additional to both anyway.

The initial reason for otherParties was to enable third-party behavioural advertising in an opt-in only legal environment, though there are advantages in other use cases also (such as controlling malware).

Blocking is already a major factor for the web, through ad blocking or other content blocking. Using otherParties array will help sites regain some control over arbitrary blocking because UAs will tend over time to take account of it.






-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org> ] 
Sent: 07 May 2017 21:28
To: David Singer <singer@apple.com <mailto:singer@apple.com> >; Rob van Eijk <rob@blaeu.com <mailto:rob@blaeu.com> >
Cc: 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

Hi David,


I agree that this is a potential can of worms.

Background: Shane proposed that a publisher can list all known/expected
third parties in an other-party field. He also suggested that the
publisher can request that other third parties are blocked. Since this
blocking is triggered by the publisher himself, it may be less
controversial. The basic idea is that it helps the publisher to ensure
that only compliant third parties are loaded.

On the downside, it would allow the publisher to constrain the business
of third parties that the publisher uses.

An alternative could be to indeed only talk about DNT;0/1.

In such a version (with no explicit blocking), the outcome would look as
follows:
1. other-parties declares a list of third party
2. A site-wide exception triggers sending DNT;0 to those listed third
parties (all unlisted third parties continue to receive DNT;1)
3. The publisher can use a JS API to ask "what additional third parties
occured on the site".

This whole scenario would not use blocking.

I guess it is up to shane to decide whether a non-blocking version
satisfies his requirements or not.


Regards,
matthias


On 05.05.2017 23:28, David Singer wrote:
> 
>> 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.
>