Controller Specific Consent

[michael-oneill]

If a controller operates many different web domains they often want to ask for consent, or let it be revoked, for multiple domains in one go. This can be implemented using the current API by using the domain property, but this only lets sites register consent for subdomains i.e. using "cookie rules". It could perhaps be implemented via the dynamic creation of iframes inside a a "click" handler but this would not be efficient beyond a handful of domains, and would depend on browsers implementing the API in a way that would allow this.

Controllers can declare themselves in the "controller" TSR property so consent could be applied to a named set of domains that have the identical "controller" property as the caller in their own TSRs. Before granting the exception the user agent can check that the caller domain is listed in the "same-party" array of the target domain, i.e. that the sites mutually refer.

This could be implemented by having a new property "domains" in the API dictionary (the TrackingExceptionPropertyBag), which would be an array of strings indicating the domains where consent is being asked to be registered. There would be no wildcard characters allowed, each "target" domain would have to be explicitly listed.

The user agent would check the controller properties were identical for each domain, and that each TSR same-property array referred back to the calling origins domain. This procedure would only need to be checked when the exception "store" API is called, and would only require the prefetching of the target domains TSRs.

The existence of the "cookie rules" domain property increases the clock-cycle cost in implementing the API because all subdomain components must be checked for every request. This new parameter would make the domain property redundant.

[mschunte2]

Hi Mike, could this be emulated by a series of calls to the API? (one for each domain)? If yes, I suggest adding some text saying so (without changing the API) matthias

…

On 27.02.2017 21:56, michael-oneill wrote: If a controller operates many different web domains they often want to ask for consent, or let it be revoked, for multiple domains in one go. This can be implemented using the current API by using the domain property, but this only lets sites register consent for subdomains i.e. using "cookie rules". It could perhaps be implemented via the dynamic creation of iframes inside a a "click" handler but this would not be efficient beyond a handful of domains, and would depend on browsers implementing the API in a way that would allow this. Controllers can declare themselves in the "controller" TSR property so consent could be applied to a named set of domains that have the identical "controller" property as the caller in their own TSRs. Before granting the exception the user agent can check that the caller domain is listed in the "same-party" array of the target domain, i.e. that the sites mutually refer. This could be implemented by having a new property "domains" in the API dictionary (the TrackingExceptionPropertyBag), which would be an array of strings indicating the domains where consent is being asked to be registered. There would be no wildcard characters allowed, each "target" domain would have to be explicitly listed. The user agent would check the controller properties were identical for each domain, and that each TSR same-property array referred back to the calling origins domain. This procedure would only need to be checked when the exception "store" API is called, and would only require the prefetching of the target domains TSRs. The existence of the "cookie rules" domain property increases the clock-cycle cost in implementing the API because all subdomain components must be checked for every request. This new parameter would make the domain property redundant. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWJLRhsb2Jk301OxPEm847BMlX_FyPcPks5rgziOgaJpZM4MNnbo>.

[michael-oneill]

Nope, the SOP stops that (only top level domain or its subdomains) From: mschunte2 [mailto:notifications@github.com] Sent: Monday, March 6, 2017 3:34 PM To: w3c/dnt <dnt@noreply.github.com> Cc: michael-oneill <michael.oneill@baycloud.com>; Author <author@noreply.github.com> Subject: Re: [w3c/dnt] Controller Specific Consent (#19) Hi Mike, could this be emulated by a series of calls to the API? (one for each domain)? If yes, I suggest adding some text saying so (without changing the API) matthias

On 27.02.2017 21:56, michael-oneill wrote: If a controller operates many different web domains they often want to ask for consent, or let it be revoked, for multiple domains in one go. This can be implemented using the current API by using the domain property, but this only lets sites register consent for subdomains i.e. using "cookie rules". It could perhaps be implemented via the dynamic creation of iframes inside a a "click" handler but this would not be efficient beyond a handful of domains, and would depend on browsers implementing the API in a way that would allow this. Controllers can declare themselves in the "controller" TSR property so consent could be applied to a named set of domains that have the identical "controller" property as the caller in their own TSRs. Before granting the exception the user agent can check that the caller domain is listed in the "same-party" array of the target domain, i.e. that the sites mutually refer. This could be implemented by having a new property "domains" in the API dictionary (the TrackingExceptionPropertyBag), which would be an array of strings indicating the domains where consent is being asked to be registered. There would be no wildcard characters allowed, each "target" domain would have to be explicitly listed. The user agent would check the controller properties were identical for each domain, and that each TSR same-property array referred back to the calling origins domain. This procedure would only need to be checked when the exception "store" API is called, and would only require the prefetching of the target domains TSRs. The existence of the "cookie rules" domain property increases the clock-cycle cost in implementing the API because all subdomain components must be checked for every request. This new parameter would make the domain property redundant. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWJLRhsb2Jk301OxPEm847BMlX_FyPcPks5rgziOgaJpZM4MNnbo>.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBCIsUtyhQBll8SbNb0_h9tP8loPyXMks5rjBlggaJpZM4MNnbo> .

[michael-oneill]

Thinking about it a bit more, it could work, as long as the API can be called from an embedded context e.g. an iframe, which is implied in the text anyway. We should maybe have a sentence to clarify that.

To improve user experience the JS API should also be available to Web Workers, e.g. the navigator.*TrackingException calls and navigator.doNotTrack should be accessible through WorkerNavigator

The user cannot sensibly be asked for their informed consent without being informed of the identity of the controllers, and it makes sense that there would have to be a TSR in the context presenting the UI, with a "same-party" array (or similar) specifying the other domains. To help user control we could suggest that the UA checks it if there is a "third-party cookie block" setting enabled, i.e. DNT Exceptions would not be blocked (when third-party cookies are blocked) if the domain targeted is defined as controlled by the same-party.

We should also suggest that UAs let users revoke all the Exceptions registered for domains issued by the same controller (as declared in their "controller" array property).

[mschunte2]

Text proposal: If a user-granted exception is stored, user agents will be able to provide more context to their users if they keep information from the TSR.

[michael-oneill]

Non-normative text to go at end of Section 7.2

If a user-granted exception is stored, user agents will be able to provide more context to their users if they also store a reference to the Tracking Status Resource of the requesting document origin. For example, when a user revokes their consent for a Tracking Exception in a user agent provided UI, the user could be prompted to ask if they want to revoke other existing Tracking Exceptions for domains managed by the same Data Controller.

[dwsinger]

If we adopt, I would suggest simplifying the text slightly:

If a user-granted exception is stored, user agents can use the the Tracking Status Resource to provide more context to their users. For example, when a user revokes their consent for a Tracking Exception in a user agent provided UI, the user could be prompted to ask if they want to revoke other existing Tracking Exceptions for domains managed by the same Data Controller.