- From: David Singer <singer@apple.com>
- Date: Sun, 06 May 2012 09:41:42 +0200
- To: Nicholas Doty <npdoty@w3.org>
- Cc: Tracking Protection Working Group <public-tracking@w3.org>
I *thought* the consensus in DC was that we would explore having two calls; that a web-wide exception for a third party would be a separate call. But the action seems to be telling me that the consensus was something else. Am I mis-reading the action? On May 6, 2012, at 3:50 , Nicholas Doty wrote: > Sorry for my confusion, I thought the conclusion of our breakout session in DC was agreement that we should enforce origin restrictions with these calls -- that only the first party can request exceptions on its sites and Web-wide exceptions for a third party can only be requested on that party's origin (in an embedded iframe, for example). Do we want to allow, for example, Analytics.com to request a site-wide or site-specific exception when its script or iframe is embedded on News.com? > > It would be good for us to document that answer either way, and if we don't intend to allow such requests (what I thought had been consensus in DC) then we can ignore the tricky questions you identify below. > > Thanks, > Nick > > On May 4, 2012, at 7:44 AM, David Singer wrote: > >> These actions ask that the API be clarified such that a Javascript executing >> >> requestSiteSpecificTrackingException( <DOMstrings>, <callback>, [<sitename>], [< explanationString>], [<detailURI>] ) >> >> be clarified that it is permitted that third parties as well as first parties can make this request. >> >> However, this is not as simple as it looks. This API asks for an exception for the site-pairs (using the notation first-party/third-party): >> >> script-origin/DOMstring >> script-origin/DOMstring >> >> i.e. the first half of the pair is implied by the script-origin and assumed to be the 1st party. >> >> If a third-party were to call it, it would have to take the form >> >> DOMstring/script-origin >> >> I could certainly write that text, but this presumes that both the sites and the user-agents can reliably determine which sites have first-party status, and which have third-party status. Unfortunately, all the definitions currently use 'judgment calls' (e.g. knowing which sites the user has knowingly and meaningfully interacted with). >> >> However, this assumption underlies the checking of the accumulated database; do I send DNT:0 or DNT:1 to a host? Well, gather the 1st party: >> * if the host is equal to the 1st party, send the appropriate signal >> * otherwise, form the pair 1st-party/host-domain and see whether it matches one entry in the database >> -- if it does, send DNT:0, else send DNT:1 >> >> Since we currently have this assumption, I suggest we add the following to 6.4.2 of the TPE spec. >> >> * * * * >> >> The execution of this API and the use of the resulting permission (if granted) use two 'implicit' parameters: when the API is called, the domain of the origin of the script (script-origin), and the domain of the top-level browsing context (tld-domain). >> >> When the API is called, if script-origin is equal to tld-domain, and permission is granted, then the set of tuples >> >> script-origin/DOMstring (once per DOMstring) >> >> is added to the database of remembered permissions. Otherwise the single tuple >> >> DOMstring/script-origin >> >> is added to the database. In this case, there must be only one DOMstring. >> >> While the browser is about to send an HTTP request to a host (whose domain is host-domain) while DNT is active and enabled, then if the tuple >> tld-domain/host-domain >> matches any tuple in the database, a DNT:0 header is sent, otherwise a DNT:1 header is sent. >> >> This enables >> * first parties to ask for site-wide permission (DOMstring="*") or specific permissions (otherwise) >> * third parties to ask for a web-wide permission (DOMstring="*") or specific permission (otherwise) >> >> * * * * * * * >> >> I am sure I am missing something. and this text necessarily covers more ground than the actions, let the discussion commence!! >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> > David Singer Multimedia and Software Standards, Apple Inc.
Received on Sunday, 6 May 2012 07:44:46 UTC