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

I think the proposal from Shane on a method to request a Web-wide exception [0] is an alternate to a single method that handles both site-specific and web-wide exceptions. I suspect that having a separate methods will make this clearer.

I still think we can conclude that third-parties shouldn't call these methods: the publisher is asking for a site-specific exception for their trackers and the Web-wide exception is only requested when that tracker is a first party (although potentially in an iframe), right?

Thanks,
Nick

[0] thread starting here: http://lists.w3.org/Archives/Public/public-tracking/2012May/0228.html

On May 14, 2012, at 9:28 AM, Matthias Schunter wrote:

> Hi DNT Team,
> 
> I second David's suggested text (near the end). Are we all OK with
> inserting it into the spec for further review?
> 
> Regards,
> matthias
> 
> 
> On 04/05/2012 16:44, 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.
>> 
>> 
>