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 14:52:07 UTC