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

> On Aug 28, 2017, at 8:08 , Rob van Eijk <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?

That was the reason for the target-specific site-specific exception; for sites that don’t want to ask you to trust everyone who might be or is embedded.

> 
> 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.  you’re trusting the top-level site.

There’s tension both ways.

> 
> 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
> 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                     <;
> > Senior Principal Scientist, Adobe   <;
> > 
> > 
> > 
> > 
> 
> Dave Singer
> 
> singer@mac.com

Dave Singer

singer@mac.com

Received on Tuesday, 29 August 2017 00:49:30 UTC