Re: Issue-187

Hi Mike

I am not sure I understand all you are saying here, so, let's explore a bit.


On Mar 15, 2013, at 14:07 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> Another use-case for site specific DNT:1 came up at the Berlin Global Considerations meeting, which will also be a common occurrence outside of the EU. The current API for site-specific exceptions only allows for the setting of DNT:0, or the registration of Tracking Consent, after a first-party site has established it. A user may be able to remove this exception, or revoke the consent for tracking, by using a user-agent specific UI but this may not be present in their particular browser and the form of the UI cannot be under the control or part of the user experience of the first-party site.
>  
> As there is no way with the current API to specify an expires or max-age qualifier and no way for a first-party site to programmatically revoke the signal

No, there is.  I designed it not so a specific request could be revoked, but that a site could, at any time, ask for a 'clean out' reset back to a known state.  A specific cancel seemed to me to be fragile; slight differences between the setup request and the cancel might mean that 'nothing matched' and 'nothing would get cancelled', whereas a 'please revoke everything, I will set it up afresh' seems to enable the site to get back to where it wants.


> we should extend the API so that script in the first-party domain origin an existing DNT:0 signal can be reset to the general preference, allowing the site to register in the user-agent that consent has been revoked. This would be a minor increment to the work needed to implement a site-specific exception and should be done for consistency, and to meet the requirements of regulators at least in Europe.
>  
> The other use-case I previously pointed out was the ability for a first-party site in the EU to signal its embedded third-parties, in the case that the general preference is unset, that consent was required,  for example because the first-party site or the user was in an EU jurisdiction, but had not been obtained. This would require the site-specific API to register DNT:1 so that the third-parties could take the correct course of action even if the DNT general preference was unset.

Ah, this is for the case where the user has no preference set, but the site is aware that its third parties need to get a DNT:1 because the site is EU and it needs its third parties (who might serve sites from many jurisdictions and might not be in the EU) to get an explicit DNT:1?

>  
> The site specific API should have the ability, for the document origin and a list of embedded third-parties (targets), to set the following :
> ·        Set DNT to 0
> ·        Set DNT to 1
> ·        Set DNT to the General Preference i.e. 0, 1, or unset
>  
> This could be done, for example, by supplying another DOMString member to the StoreSiteSpecificExceptionPropertyBag dictionary, specifying either “set-dnt-0”, “set-dnt-1” or “revoke”.
>  
> In the future we could add qualifiers to this such as “;Expires=Fri, 15-Mar-2013 21:47:38 GMT”.
>  
> It would then be possible for script in the top-level origin to concatenate calls to the API, for instance to set DNT:1 for a set of domains and DNT:0 for a subset of them. At the moment we do not have the ability to specify wild-cards or regex expressions for the targets but we do have a rudimentary way to do it by not supplying an arrayOfDomainStrings, equivalent to *.*. At some point we should add regex or wild-card functionality to the definition of arrayOfDomainStrings.

We have resisted wild-cards here because of public-suffix and cross-site issues.  Do we really need them?

> This would also give sites the ability to identify embedded resources differentiated by more than just the domain origin.
>  
>  
> -Mike
>  
>  

David Singer
Multimedia and Software Standards, Apple Inc.