New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API callers must have a TSR #21

Closed
michael-oneill opened this Issue Mar 9, 2017 · 12 comments

Comments

Projects
None yet
4 participants
@michael-oneill
Collaborator

michael-oneill commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mschunte2

mschunte2 Mar 13, 2017

Collaborator

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

Collaborator

mschunte2 commented Mar 13, 2017

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

@royfielding

This comment has been minimized.

Show comment
Hide comment
@royfielding

royfielding Mar 13, 2017

Collaborator

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.

Collaborator

royfielding commented Mar 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@michael-oneill

michael-oneill Mar 14, 2017

Collaborator

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.

Collaborator

michael-oneill commented Mar 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@michael-oneill

michael-oneill Mar 19, 2017

Collaborator

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.

Collaborator

michael-oneill commented Mar 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@michael-oneill

michael-oneill Mar 19, 2017

Collaborator

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.

Collaborator

michael-oneill commented Mar 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mschunte2

mschunte2 May 15, 2017

Collaborator

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

Collaborator

mschunte2 commented May 15, 2017

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

@michael-oneill

This comment has been minimized.

Show comment
Hide comment
@michael-oneill

michael-oneill May 21, 2017

Collaborator

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.

Collaborator

michael-oneill commented May 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dwsinger

dwsinger May 22, 2017

Collaborator

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.

Collaborator

dwsinger commented May 22, 2017

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 comment has been minimized.

Show comment
Hide comment
@mschunte2

mschunte2 Jun 14, 2017

Collaborator

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

Collaborator

mschunte2 commented Jun 14, 2017

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

@royfielding

This comment has been minimized.

Show comment
Hide comment
@royfielding

royfielding Jun 30, 2017

Collaborator

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.

Collaborator

royfielding commented Jun 30, 2017

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.

royfielding added a commit that referenced this issue Jul 1, 2017

Fix the wording introduced for issue #21 so that it doesn't conflict
with previous consensus regarding TSR validity and the defaults for
controller and policy, all of which were already defined (where it belongs).

Move definition of user-granted exception to its defining section and
rewrite the confusing overview,

Fix an old reference to window.doNotTrack (now on Navigator).
Remove informative distinctions when that is invalid or obvious.
Remove notes that are redundant to the normative content.
Use defined term "target resource" instead of request target or
other variations on the theme.

Editorial fixes due to changes in how respec handles crossrefs.
@mschunte2

This comment has been minimized.

Show comment
Hide comment
@mschunte2

mschunte2 Jul 2, 2017

Collaborator
Collaborator

mschunte2 commented Jul 2, 2017

@royfielding

This comment has been minimized.

Show comment
Hide comment
@royfielding

royfielding Jul 2, 2017

Collaborator

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.

Collaborator

royfielding commented Jul 2, 2017

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.

royfielding added a commit that referenced this issue Jul 3, 2017

issue #21 - require the policy property to be in the TSR when calling…
… the API to store an exception; change editorial notes to the ednote class; fix places where permission/exception change required an or some other word

@mschunte2 mschunte2 closed this Sep 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment