RE: Propagating site-wide consent without Javascript

The existing (other) web APIs cannot achieve the things the Exception API can.

1) The Same Origin Policy (SOP) stops one origin setting cookies or otherwise changing the state of another origin's browsing context.  Cross-origin communication of state changes can be done in an ad-hoc way e.g. by dynamically creating iframe or other elements but 
this requires prior agreement between the parties. One of the motivating principles behind the JS API was to avoid that. https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-principles.

2) Site specific consent cannot be implemented using HTTP cookies alone. It is possible  to store consent in a first-party cookie and use other APIs to communicate that to third-parties, e.g. by editing embedded element URIs, but again this requires prior agreement between companies.

We can describe protocols for exchanging this information but this will never be as transparent or as effective as DNT:0 managed by the browser.

We can come up with alternative schemes (perhaps not using JS) for specifying DNT: 0, or storing specific "dnt-override" cookies in other origins, but why would that be any more acceptable to the browser companies than the Exceptions API?

If we are being told browser companies (other than Microsoft) will not implement the API then IMO we should come up with recommendations on the necessary cross-origin protocols, but keep the API because it is already in use and will always be a more effective solution.






> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
> Sent: 20 February 2017 13:12
> To: public-tracking@w3.org (public-tracking@w3.org) <public-
> tracking@w3.org>
> Subject: Propagating site-wide consent without Javascript
> 
> Hi Folks,
> 
> during our last call, David suggested that we should put the Javascript
> API at risk. By doing so, we can continue towards recommendations even
> if the API is not implemented by the participants.
> 
> I would like to now kick-off a "what if" discussion.
> 
> The javascript API serves IMHO three purposes:
> 1 - To store site/web-wide exceptions
> 2 - To propagate consent from the site to its sub-elements (e.g. the
>   site
>   obtained site-wide consent and all its sub-elements (such as
>   analytics) will then receive a DNT;0 to signal that they are
>   permitted to track.
> 3 - To provide transparency to the user (who can check what
>   consent/exceptions are stored in his browser)
> 
> If the Javascript API were removed, then consent can be stored using
> cookies or other means (point 1), transparency would need to be provided
> (at a limited level) by the sites (point 2).
> 
> I would now kick off a discussion how consent could be forwarded from a
> site to its subsidiaries. Options I see
> 
> Option 1: Javascript API + DNT;0 header (current solution; at risk)
> 
> Option 2: Some other way to trigger sending DNT;0 (e.g. we could define
> a "site-wide exceptioN" response header that triggers sending DNT;0 to
> other elements
> 
> Option 3: Encoding in URLs? Some Javascript tricks? Other?
> 
> 
> What do you think? Opinions?
> 
> 
> Regards,
> matthias
>

Received on Thursday, 23 February 2017 11:31:11 UTC