RE: Proposed Resolution / Consensus for Monday's call.

So if facebook.com visited as first-party executes a storeTrackingException
(site != "*", with targets =null, undefined, or empty), then when
facebook.com is a subresource on another site it still gets DNT:1? That is
not how I read it, but it could be implemented that way. 

This is not how Microsoft did it though (or Bouncer), but we can change
that.

What about the other way round. If a facebook.com iframe, i.e. a
sub-resource,  executes a web-wide storeTrackingException (site = "*",
targets = ["facebook.com"], empty or null) does it receive DNT:1 when
visited as a first-party?

It makes it slightly more complicated to implement because you have to store
an extra boolean  per UGE (this UGE was triggered by web-wide call). If this
is how it should be we should say so.



-----Original Message-----
From: David Singer [mailto:singer@mac.com] 
Sent: 28 August 2017 15:52
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: Roy T. Fielding <fielding@gbiv.com>; Matthias Schunter
<mts-std@schunter.org>; public-tracking@w3.org
Subject: Re: Proposed Resolution / Consensus for Monday's call.


> On Aug 26, 2017, at 3:44 , Mike O'Neill <michael.oneill@baycloud.com>
wrote:
> 
> 1) Site-specific UGEs in iframes with a null or empty "targets" array is
> exactly equivalent to web-wide consent for the iframe's domain. 

It most certainly is not.

A web-wide exception asks that wherever I, the target site, occur in your
browsing, whether a top-level or embedded call, I get an exception i.e.
DNT:0. Just for me.

A site-specific exception asks that whenever I am the top-level browsing
context, either selected or all embedded sites, as well as me, get an
exception, i.e. DNT:0.

These are not the same.


> 2) They are is a bigger risk than web-wide UGEs, because all the child
> subresources (of the script origin) become targets.
> 3) The fingerprinting risk is only when it is done by a third-party. There
> is hardly any advantage for a first-party to do it because they could just
> use a cookie. UAs will probably clear the UGE store when cookies are
purged
> anyway, so there is then no point at all to it for first-parties.
> 
> We could suggest in the fingerprinting note that UAs consider blocking
site
> specific (or even web-wide) UGEs in subresources
> 
> If we had not run out of time, a far better solution for everyone would be
> to ban all UGEs in iframes, and extend the API so domains in the
same-party
> array can be given UGEs. It is far more scalable, will be less damaging to
> the user experience and stops third-party fingerprinting.
> 
> 
> 
> Mike
> 
> 
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com] 
> Sent: 26 August 2017 00:04
> To: Matthias Schunter <mts-std@schunter.org>
> Cc: public-tracking@w3.org (public-tracking@w3.org)
<public-tracking@w3.org>
> Subject: Re: Proposed Resolution / Consensus for Monday's call.
> 
>> On Aug 25, 2017, at 7:30 AM, Matthias Schunter (Intel Corporation)
> <mts-std@schunter.org> wrote:
>> 
>> Dear TPWG,
>> 
>> 
>> I had a quick chat with Mike. Our proposal is to:
>> (a) rollback the editors draft to our original consensus
> 
> The only consensus we had was the last CR document.
> 
> Personally, I would be a lot more comfortable about this discussion
> if Shane's use cases were actually present in the specification instead
> of being assumed based on past discussions.  After all, we had a great
> number of discussions, and my experience has been that "consensus"
> is in the eyes of the beholder.
> 
> Shane, do you have those use cases documented?
> 
>> (b) suggest to add an implementation recommendation that helps
>> mitigating the fingerprinting risk: By limiting the number of
>> site-specific UGE that a domain can store, we also limit the capability
>> to fingerprint.
> 
> I don't think that will work.  The number stored is the number of bits,
> so just eight would be enough (when combined with other factors).
> We might limit the number of confirmation calls, since a legitimate
> use case should only make one or two such calls per script, but
> a fingerprinting script could get around the API limitation by
> making N embedded requests that simply return the received DNT value.
> 
> Note that the WG actually had this discussion before (with Nick, IIRC).
> The only protection against fingerprinting (specifically for this
> attack) that we could think of is already in the fingerprinting
> section (a suggestion to restrict the number and frequency of API
> calls).
> 
>> Below are more detailed notes.
>> 
>> Any comments and feedback are welcome!
>> 
>> Note that we are aware that anyone (including sub-resources) can store
>> web-wide exceptions. I suggest to see how the adoption evolves and then
>> browsers can determine whether additional checks and balances may be
> needed.
> 
> So, we should remove the limitation that was added two weeks ago?
> 
>> Regards,
>> matthias
>> 
>> 
>> ------------------8<---
>> 
>> Original (still valid) consensus:
>> - 1st party and third parties
>> 	- can ask for web-wide and site-specific UGE
>> 	- both for the script origin only
> 
> Umm, I don't understand.  The script origin (where the script was
> downloaded from) has nothing to do with it.  The "effective script origin"
> is the origin presumed by the browser security model, which includes
> the scheme, host, and port of the immediate document within which the
> script is loaded and running. This corresponds to the "document-origin"
> used within the CR spec (if we ignore scheme and port).
> 
> David is right: the CR API limits storeSiteSpecificTrackingException
> to the script's document domain, not the top-level document's domain:
> 
>  "If the document-origin would not be able to set a cookie on the
>  domain following the cookie domain rules [RFC6265] (e.g. domain is not
>  a right-hand match or is a TLD) then the duplet MUST NOT be entered
>  into the database and a SYNTAX_ERR exception SHOULD be thrown."
>  https://www.w3.org/TR/tracking-dnt/#exceptions-javascript-api-rqst
> 
> whereas I incorrectly translated that to
> 
>  "For a site-specific exception, a user agent MUST NOT store the duplets
>  and MUST reject the promise with a DOMException named "SecurityError" if
>  the script's site domain would not be able to set a cookie on the site
>  following the cookie domain rules [RFC6265],"
> 
>
https://w3c.github.io/dnt/drafts/tracking-dnt.html#exception-javascript-api-
> store
> 
> which is confusing: it was supposed to be "the script domain", which I
> had as a defined term for the document.domain of the script's responsible
> document (the currently HTML5ish translation of what we were calling
> document-domain in the CR).  Alternatively, we can just say "if the
> script would not be able to set a cookie on the site", since the same
> origin rules are what constrains a script from doing so.
> 
> When a site-specific exception is desired, the site portion of the API
> defaults to the top-level browsing context, which is not the same as
> the effective script origin if an iframe running the script is being
> loaded from a different origin (same-party or third-party).
> It was my understanding from the list discussions that this is a specific
> use case that the API is designed to support.  I think that was Shane's
> opinion, as well.  I even included a paragraph describing it in section
6.3.
> Was that use case only supposed to work for web-wide exceptions?
> 
> In other words, the use case was that a given site would ask for
> a site-specific exception for the following parties, with
> each party given an iframe in which to explain their specific
> privacy policies (or adherence to some standard) and some form of
> script-activated checkmark in each iframe to collect the user's
> informed consent for that party.
> 
> That won't work for site-specific consent given the API in CR
> nor as intended for the current draft. But what is supposed to work?
> 
> For example, the use case of a site asking for and collecting
> consent within its own browsing context, while only loading information
> within third-party frames, will work with the above restrictions.
> But only for that specific site (not for same-party sites).
> 
> Note that there are no such restrictions in the CR on removing
> or confirming a site-specific exception, nor on storing a
> web-wide exception.  Any script on any site can store a web-wide
> exception that applies to any domain.
> https://www.w3.org/TR/tracking-dnt/#exceptions-javascript-api-ww-rqst
> 
> Likewise, the use case of a group of same-party sites asking
> for and obtaining an exception for multiple third parties upon all
> of the same-party sites is very interesting, but not at all
> satisfied by the drafts to date.
> 
> The way I could see that working is by proposing a new API
> that retrieves the current TSR for the effective script origin
> (IFF it is the same as the top-level document origin), reads the
> same-party array in that TSR, retrieves the TSR from each of those
> same-party origins (to verify that they do have the same controller),
> and then store [origin, target] duplets for each of those
> origin x target combinations.
> 
>> Current editors draft:
>> - 1st party
>> 	- can ask for web-wide and targeted UGE
>> 	- both for the script origin only
>> - third parties
>> 	- can ask (only) for site-specific UGE
>> 	- web-wide is not allowed
>> 
>> Shortcomings of the current draft:
>> - site-specific UGE poses fingerprinting risk (Mike)
>> - web-wide for sub-element are needed for
>> consent portal (Shane)
>> 
>> Proposed modifications of the editors draft:
>> - Back to original consensus (to address Shane's usage)
>> 	- 1st party and third parties
>> 		- can ask for web-wide and site-specific UGE
>> 		- both for the script origin only
> 
> I'd prefer that we clarify the use case, since the above two are
> contradictory and wouldn't support Shane's case.
> 
>> - Mitigate fingerprinting risk by NOTE that suggests
>>    that browsers may limit the number of stored site-specific
>>    exceptions per top-level domain.
> 
> We already have that section.  We could certainly add more to it.
> https://w3c.github.io/dnt/drafts/tracking-dnt.html#privacy.fingerprinting
> 
>> Assessment of proposed consensus:
>> + A compliance portal (e.g. google) can now register web-wide UGE for
>> same party domains (e.g. youtube).
> 
> How?  That implies we either remove the restriction on web-wide or
> come up with a new API for same-party.
> 
>> + The limited number of site-specific user-granted exceptions can
>> minimize fingerprinting risk
> 
> See above.
> 
>> - If web-wide user-granted exceptions are mis-used, additional checks
>> and balances may be needed in the future.
> 
> Personally, I think it is more valuable to support a portal of exception
> granting than it is to protect against misuse of the API (aside from
> the fingerprinting attack).  The reason being that use of the API just
> to send DNT:0 to a target, without first obtaining legitimate and
> informed consent from the user (a process we don't even control),
> does nothing other than prove an intent to deceive.  It can be easily
> traced by storing the effective script origin and/or document URL
> along with each duplet, which is already suggested by the spec, and
> doesn't provide any more benefit to the attacker than simply ignoring
> DNT entirely.
> 
> Hence, my preference is to reiterate that several times in the draft,
> instead of placing origin restrictions on storing exceptions, and
> try to find ways to limit fingerprinting or information leaks by
> limiting the remove and confirm APIs to duplets that were stored by
> the same effective script origin.
> 
> If sites ever do abuse the API, browsers can trigger an additional
> confirmation dialog upon use of the API.  Painful, but possible.
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <https://www.adobe.com/>
> 
> 
> 
> 

Dave Singer

singer@mac.com

Received on Monday, 28 August 2017 15:40:11 UTC