API callers must have a TSR

[michael-oneill]

If subresource iframes can register a DNT Exception then they should have to have a TSR and the UA should check for it. I mentioned this somewhat in issue #19, but here the point is separated out.

The user is more aware of the site they have visited, the top-level context whose URL is in the location bar, but will probably be unaware of the identity of the controllers of subresource iframes.

If a subresource browsing context does not have a TSR, or the TSR does not include a "controller" property, calls to store*TrackingException should be ignored.

[mschunte2]

text proposal: A site calling registering a user-granted exception MUST publish a valid TSR.

[royfielding]

I suggested that it is better to require that the domains registered as exceptions have a TSR, since that removes the question of how (or by what site) they are registered. However, we could also require that site corresponding to the domain context that calls the exception API also have a TSR.

Note that the controller property has a default of the site's domain, so it always "exists" even if it is not present as a property in a given TSR. There is no need to require it.

[michael-oneill]

Good point about the controller property.

The domains registered as exceptions will always be the same, or a subdomain (of the maindomain) of the document origin, but yes, they should all of them have a TSR.

[michael-oneill]

I think there should still be a requirement for a controller property, or some other way to identify the controller(s) of an origin, especially if the Exception is being requested by a subresource iframe.

Even if it is a visited first-party page, there may be no way find out the identity of the controller, the page might not refer to an about page or a privacy policy page.

So we should require the controller's identity to be explicitly declared in the TSR before an exception is granted.

[michael-oneill]

Normative text to go after the first paragraph in Section 7.3.1.

A Tracking Exception MUST only be granted when the document origin requesting it has a valid Tracking Status Resource at the well-known location, from which information about the domain’s controlling entity(s) and their privacy policy can be ascertained.

A user agent MAY refuse to grant a Tracking Exception for a Site-Specific “target” domain (see Section 7.3.2) which does not have a valid Tracking Status Resource at the well-known location.

[mschunte2]

2017-05-15: Mike will finalize text. Roy to put it in spec. Review in next call.

[michael-oneill]

Normative text to go after the first paragraph in Section 7.3.1. I will edit the draft an create a PR

A Tracking Exception MUST only be granted when the document origin requesting it has a valid Tracking Status Resource at the well-known location, from which information about the domain’s controlling entity(s) and their privacy policy can be ascertained.

To be valid the response to a retrieval request on the site-wide tracking resource /.well-known/dnt/ relative to the service URI must have a application/tracking-status+json</code|> media type, be valid JSON and include at least the tracking, controller, compliance and policy properties.

A user agent MAY refuse to grant a Tracking Exception for a Site-Specific “target” domain (see Section 7.3.2) which does not have a valid Tracking Status Resource at the well-known location.

[dwsinger]

As phased, this means that the UA has to do a fetch on every call. Can we make it a requirement on the site please; "A site that registers an exception MUST publish..." (Matthias).

A Tracking Exception MUST only be requested when the document origin requesting it has a valid Tracking Status Resource at the well-known location, from which information about the domain’s controlling entity(s) and their privacy policy can be ascertained.

[mschunte2]

This text was consensus in the 2016-06-01 call

[royfielding]

I apparently missed the call. The text adds arbitrary and incorrect requirements to the tracking status object that contradict how that object is defined. I am reverting those parts.

[mschunte2]

Hi Roy,

thanks a lot for double checking. I appreciate that you ensure that the text is free of contradictions.

If you find a better editorial way to implement the WG consensus, then I would appreciate a quick explanation to the public list.

An email like:

• WG consensus / intent was XXX
• The current "implementation" was YY and did not work because of WW
• I now implemented the intent by [New implementation]

This will allow us to proceed to CR faster (otherwise, we have to double check that your reverting some things do not violate the consensus we reached).

FYI: My initial impression of the logfile was "Roy did not like the consensus so he reverted our changes". While I am sure that this is not your intent, I would like to ensure that the better way you implemented our consensus is clear to everybody.

Thanks a lot!

matthias

On 01.07.2017 01:31, Roy T. Fielding wrote:

I apparently missed the call. The text adds arbitrary and incorrect requirements to the tracking status object that contradict how that object is defined. I am reverting those parts.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/dnt/issues/21#issuecomment-312393651, or mute the thread https://github.com/notifications/unsubscribe-auth/AWJLRgChD2PWrtBMpkDhGR5LTqBAsIFrks5sJYVrgaJpZM4MXxGr.

[royfielding]

Matthias, I appreciate the need to move swiftly, but publishing a logical contradiction in the spec is not an option.

It is not suitable to add arbitrary requirements and incorrect statements about validity of a TSR inside a section on the javascript API, even if we agreed on them; they would have to be reflected in the other parts of the spec as well (which are far more polished than the API sections).

Furthermore, I did explain, twice on calls and in several issues related to this one, that both controller and policy have defaults which provide the required information without requiring the presence of those properties. We did not have WG consensus to make that change and certainly don't have it now.

That's a problem with doing polls on a call and calling it WG consensus. We can't attend every call, yet I am still a member of the working group. I could object to the declared consensus on the mailing list, wait for you to reopen the issue, and fix it with permission, but that takes time that we don't have. My plan was (and is) to explain it in the summary of changes I am due to send to the list.