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

It seems to met we have 2 use cases here.

I prefer to keep both separate.(1) the NAI/DAA style call and (2) the European ePR style call (i.e., hat a web-wide exception could only be stored when the script was located on a page on the target domain (ensuring a first party interaction). A note could explain that the site owner is responsible to verify that the chosen API call style is in line with the (regional) legal framework.

Rob

-----Original message-----
From: Roy T. Fielding
Sent: Monday, August 28 2017, 7:33 pm
To: w3c/dnt
Cc: Subscribed
Subject: [w3c/dnt] Subresources can store a web-wide exception for their own target domain (#58)

A few weeks ago we changed the API so that a web-wide exception could only be stored when the script was located on a page on the target domain (ensuring a first party interaction). However, that contradicts a previous consensus that the API be callable within a portal, similar to the NAI/DAA style of consent page that might ask for a number of web-wide exceptions at once. Hence, we want subrequests (iframe-based scripts) to be able to store a web-wide exception, but only one that targets their own domains (like the limitations on cookies).



-----Original message-----
From: Mike O'Neill
Sent: Monday, August 28 2017, 5:58 pm
To: singer@apple.com; Rob van Eijk
Cc: 'Roy T. Fielding'; 'Matthias Schunter'; public-tracking@w3.org
Subject: RE: Proposed Resolution / Consensus for Monday's call.



Also I think it is good that we are looking hard at this stuff, it has to be done sometime and better we do it.




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


> On Aug 28, 2017, at 8:08 , Rob van Eijk <rob@blaeu.com <mailto:rob@blaeu.com> > wrote:
> 
> Hi David,
> 
> Just to be clear on whether site-specific exceptions fly on a site with RTB. Due to the nature of the embedded parties change over time. 
> 
> Does this mean that after an end user has granted a site-specific exception, ANY embedded parties get an exception, regardless whether they were present at the time of granting the exception or not?

well, I am talking about the design I wrote, not what Mike and Roy re-wrote. They might be different.

Yes, there were two forms of site-specific exception in the old document:
* site-specific for a specific set of embedded sites (expressed as the set of duplets [target, domain] for each domain in the array)
* site-wide, for all embedded sites  (expressed as the duplet [target, *])

There was considerable debate on whether the former was needed or not, and on whether it must be supported or not.  We ended up with the uneasy compromise that it could be expressed, but a UA could broaden the former request into the latter (but had to tell the site it had done that).

> 
> If the answer is yes, the end user grants a blanket exception for unknown embedded parties that dit not appear yet on the site.

Right. The use-case is that the top-level site doesn’t know now what advertizers it will use in future, yet is sure it won’t embed anything it doesn’t trust.

> 
> If the answer is no, the end user will have to grant the exception eacht time an new embedded party appears.
> 
> Is this a correct reflection of how the mechanism works?
> 
> Rob
> 
> -----Original message-----
> From: David Singer
> Sent: Monday, August 28 2017, 4:52 pm
> To: Mike O'Neill
> Cc: Roy T. Fielding; Matthias Schunter; public-tracking@w3.org <mailto: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 <mailto: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 <mailto:fielding@gbiv.com> ] 
> > Sent: 26 August 2017 00:04
> > To: Matthias Schunter <mts-std@schunter.org <mailto:mts-std@schunter.org> >
> > 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: Proposed Resolution / Consensus for Monday's call.
> > 
> >> On Aug 25, 2017, at 7:30 AM, Matthias Schunter (Intel Corporation)
> > <mts-std@schunter.org <mailto: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                     <" target="_blank">http://roy.gbiv.com/> <http://roy.gbiv.com/> ;;
> > Senior Principal Scientist, Adobe   <" target="_blank">https://www.adobe.com/>;;
> > 
> > 
> > 
> > 
> 
> Dave Singer
> 
> singer@mac.com <mailto:singer@mac.com> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.