otherParties & blocking

Site-specific consent (site-wide or not) has to be setup in the document-origin for its embedded subresources, so it would not make sense for a browsing context to have a non-empty otherParties array property and also execute a site-specific exception (asking for DNT:0 to be sent to parties not on its otherParties list).

If this happened then it’s a bug, they might have enabled the wrong site-specific inadvertently - for example by including someone else’s script on their site and they were unaware it initiated a site-specific exception

If web-wide consent exists then presumably the user has purposefully done that, so do not block.

So the decision matrix should be (only if the UA decides to implement otherParties  blocking behaviour):

 

To decide if a particular domain is blocked or not, and if it is not what DNT value should be sent:

 

Site-wide site-specific exists for all embedded domains, including this one

                              Empty or absent otherParties      Don’t block, send DNT:0, i.e. what Shane said

                              Non-empty otherParties               If on otherParties then send DNT:0, else block it.

 

Named-targets site-specific exists for this domain

                              Empty or absent otherParties      Don’t block, send DNT:0

                              Non-empty otherParties               If on otherParties then send DNT:0, else block it (even if also in relevant arrayOfDomainStrings).

 

Web-Wide exists for this domain 

                              Empty or absent otherParties      Don’t block, send DNT:0

                              Non-empty otherParties               Don’t block, send DNT:0

 

This way the site can decide if it wants to enable blocking behaviour (and the user can be made aware of that), and the user is protected on sites that wish to enable it.                     

 

When I say sites, this could also be an ad exchange’s iframe. But the blocking behaviour should be cumulative. i.e. if an ancestor browsing-context otherParties array indicates a domain should be blocked, it cannot be unblocked by a descendant of it.

 

Mike

 

From: Rob van Eijk [mailto:rob@blaeu.com] 
Sent: 05 May 2017 18:41
To: David Singer <singer@mac.com>; Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Cc: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: RE: fyi: Fingerprinting risk

 


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)

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>