Re: TPE latest

> On Aug 30, 2017, at 6:32 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> Roy,
>  
> This is very good, I am happy with it except for the following nits:
>  
> 6.3 para 4
>  
> A first party site's page (the top-level browsing context) might be used to obtain site-specific consent for multiple parties; e.g., using multiple iframe elements containing scripts that can convey information about each party's policies and obtain specific consent for each party. In this case, the effective script origin might be different from the site for which consent is being granted.
>  
> It can be also web-wide also now, and consent is always being granted for the script origin, or a subdomain of it (or site-specific consent for a subresource of it). Suggested change:
>  
> A first party site's page (the top-level browsing context) might be used to obtain site-specific or web-wide consent for multiple parties; e.g., using multiple iframe elements containing scripts that can convey information about each party's policies and obtain specific consent for each party. In this case, consent is being obtained for the effective script origin of the iframe's responsible document, which could be different from that of the top-level browsing context.

Actually, that should have been changed to "obtain consent for multiple parties",
since that's what the text is talking about.  We aren't worried about details here.
So, strike "site-specific" and it is fine (editorial, can be fixed at CR publication).

I don't know where you are picking up the notion that consent is always being
obtained for the effective script origin, but that would be a different topic.

> 6.3 para 6
>  
> A site can request an exception be stored even when the user's general preference is not enabled. This permits the sending of DNT only for target resources for which an expressed preference is desired. Stored exceptions could affect which preference is transmitted if a user later chooses to configure a general tracking preference.
>  
> This is a bit unclear, especially the meaning of the last sentence. We should say this is only about DNT:0, and remove the last sentence which does not really add anything. It is a MAY anyway, so best leave it to the browser provider. Suggested change:
>  
> A site can request an exception be stored even when the user's general preference is not enabled. This permits the sending of DNT:0 only for target resources for which the expressed preference is desired. 

This is only slightly rephrased from the last CR
   https://www.w3.org/TR/tracking-dnt/#exceptions-when-not-enabled
so that it wouldn't contradict the protocol requirements.  I don't think
the distinction between "sending of DNT" and "sending of DNT:0" matters
(both are true).  The second sentence is a warning, not a requirement,
which is why it uses "could" now instead of MAY.

> 6.6.1, 6.6.2, 6.6.3 description of “targets” property.
>  
> targets
> An array of target domains for which the exception applies:
> 
> 	• If targets is undefined or null, the user-granted exception to be stored is [site, *], meaning that the exception applies to all domains referenced by the site.
> 	• If targets is an empty array, the user-granted exception to be stored is [site, script domain], meaning that the exception applies only to resources that share the same domain as the effective script origin.
> 	• Otherwise, for each domain string in the targets array, a user-granted exception to be stored is the duplet [site, domain].
>  
> It is unclear if the script origin always receives  an exception, which was the case before.

No, it does not, and that was not the case before either.

  https://www.w3.org/TR/tracking-dnt/#exceptions-javascript-api-rqst

> A “domain referenced by the site” implicitly includes the script origin, and the empty array case specifically includes it, so it would make sense to cover this also for the non-empty targets case. Suggested change:
>  
>  
>  
> targets
> An array of target domains for which the exception applies:
> 
> 	• If targets is undefined or null, the user-granted exception to be stored is [site, *], meaning that the exception applies to all domains referenced by the site.
> 	• If targets is an array, the user-granted exception to be stored is at least [site, script domain], meaning that the exception applies to resources that share the same domain as the effective script origin.
> 	• Additionally, for each domain string in the targets array, a user-granted exception is stored for the the duplet [site, domain].

That change would make it impossible for a script on a main site to
store an exception for a named subdomain without also storing an
exception for the main site (for which it may not have received consent).

If a script wants to *also* store an exception for its own domain,
it can easily do so by adding [site, document.domain] to the list.

Cheers,

....Roy

Received on Thursday, 31 August 2017 00:38:51 UTC