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

I have edited the text accordingly and submitted a PR against the editors draft. I also made a new file so the changes can be read as a web document.

Subresources can now make API calls, web-wide and site specific against their own script origin not restricted to the first-party domain. The storeTrackingException web-wide can now only have a targets array referring to its own script origin (rather that the top level as Roy last had it).

I also allowed the site property for trackingExceptionExists so script can confirm any exception it can create (the fingerprinting mitigation is now in the Note)

https://w3c.github.io/dnt/drafts/tracking-dnt-compromise.html#exception-javascript-api

I edited the Fingerprinting section to add the NOTE pointing out the potential attack and suggested the mitigation.

https://w3c.github.io/dnt/drafts/tracking-dnt-compromise.html#privacy.fingerprinting

I have left the same-party checking version up there in its own file. If people want to go that way (it is more verifiable and a lot more efficient) I can quickly merge it in. 

https://w3c.github.io/dnt/drafts/samepartyawareapi.html#exceptions


Mike

-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 25 August 2017 15:31
To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: Proposed Resolution / Consensus for Monday's call.

Dear TPWG,


I had a quick chat with Mike. Our proposal is to:
 (a) rollback the editors draft to our original consensus
 (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.

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.


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

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
- Mitigate fingerprinting risk by NOTE that suggests
     that browsers may limit the number of stored site-specific
     exceptions per top-level domain.

Assessment of proposed consensus:
+ A compliance portal (e.g. google) can now register web-wide UGE for
same party domains (e.g. youtube).
+ The limited number of site-specific user-granted exceptions can
minimize fingerprinting risk
- If web-wide user-granted exceptions are mis-used, additional checks
and balances may be needed in the future.

Received on Friday, 25 August 2017 19:25:08 UTC