Re: do we have cause for a call on monday?

> On Jul 31, 2017, at 11:31 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> Roy, the previous API only had the domain property (in the dictionary), not
> the arrayOfDomainStrings which was just for site-specific. The domain
> property defaulted to script-origin domain or it could specify subdomains
> off the main domain (only). With the latest change an iframe can set
> web-wide on other domains (via the target property) unrelated to its main
> domain.

The last CR

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

defines it as 

  The single duplet [ * , document-origin] or [ * , *.domain] (based on
  if domain is provided and is not null and not empty) is added to the
  database of remembered grants.

> You are correct that the old API evolved to allow iframes to register
> web-wide for their own domain (or subdomain), but that is why we added the
> TSR requirement as a check. 

I think there are a lot of things that people think the old API specified
that were never actually specified.  That's why I made drastic changes
for readability (if nothing else).  Let's just focus on what we want
the API to specify now.  In this case, I think we should add a paragraph
for web-wide duplets requiring that the user agent check that the target
domain is one that the effective script origin can set a cookie upon.
Will that be sufficient?

> For web-wide exceptions under this new structure, perhaps the UA  must
> require a valid TSR, and either check the target domains each have a TSR, or
> check they are referenced in the script-origin TSR's same-party property. 

A TSR is already required of the calling site, which the above requirement
would cause it to be the same origin as the web-wide target.

> On 9.1, I think the DPAs have a pretty good understanding of the TPE.

Clearly not.

> Specifying that browsers have the general preference defaulted on in Europe
> could be a way to signal to US based sub-resource servers that they are
> being accessed in an opt-in jurisdiction. It might be true that US companies
> will ignore it, but we cannot know they will or what will happen if they do.
> 
> I think those decisions are best left to the compliance document drafters.

Mike, that is a consensus working group decision, already made, that cost us
the first three months or so of work to get a reasonable compromise.
It is the only reason we have a draft at all.  All later decisions are based
on that premise. It defined the semantics of the HTTP header field DNT,
which is not allowed to be changed by a compliance document.

We cannot prevent DPAs from willfully ignoring the requirements that are
already in the specification, but we can continue to explain exactly what
those requirements are and why they were made.  Nothing in that section is
specific to the EU or any other region.

....Roy

Received on Tuesday, 1 August 2017 18:27:53 UTC