Re: Actions 183 and 176 (which seem to be the same)

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

Received on Sunday, 6 May 2012 01:50:21 UTC