- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Fri, 25 Aug 2017 20:24:14 +0100
- To: "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>, <public-tracking@w3.org>
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