W3C home > Mailing lists > Public > public-tracking@w3.org > August 2017

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

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>
Message-ID: <1b0b01d31dd7$bca5e840$35f1b8c0$@baycloud.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:39 UTC