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

> On Aug 28, 2017, at 8:39 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> 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. 

I don’t know what the rewrite says, as it has mixed the two exceptions into one call.

What the old API said was that a site-specific call by Facebook with no targets would store the duplet

[facebook, *]

when facebook occurs on another site, say IBM, then the duplet to match is

[IBM, facebook]

which doesn’t match [facebook, *]


> 
> 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
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 28 August 2017 15:53:50 UTC