W3C home > Mailing lists > Public > public-tracking@w3.org > May 2012

ACTION-202 Alternative to explicit/explicit API

From: Matthias Schunter <mts-std@schunter.org>
Date: Wed, 23 May 2012 00:06:46 +0200
Message-ID: <4FBC0DF6.30504@schunter.org>
To: "public-tracking@w3.org" <public-tracking@w3.org>
Hi Folks,

as promised, I enclosed and outline how to resolve the issue of
explicit/explicit exceptions.
The goal is to allow for transparency (what third parties are used) and
control (what third parties did I consent to) while simplifying the

Comments/feedback is welcome!

------------------------8<---------- Outline explicit/explicit approach
V01 --------------
1. JAVASCRIPT API: We only allow site-wide and web-wide exceptions.
I.e., a server mysite can ask for exceptions for all its third parties
or ask for an exception for itself (as third party) on all 1st party sites.

2. Well-known URL: OPTIONAL List of direct third parties (maybe also any
and/or responsibilities) [Empty means that no specifics are promised] If
a site decides to post a list, then they bind themselves to the list.
Subsequent enlargements to the list requires calling the javascript API

3. Semantics: What does this mean?
   a) When a server asks for a site-wide exception and has posted  a
list of third parties, then at least these third parties must
        receive DNT;0 from this point on. This means that a user may
snapshot the parties at the time of the API call.
   b) When a server asks for a site-wide exception and has not posted a
list of third parties, then no promises are made
        and DNT;0 will be sent to all third parties on this site.

4. Telling the server what exceptions are stored on the client
   a) If the client has no site-wide exception for this site, then it
sends DNT;1
   b) If the client has a site-wide exception for a site, then it sends
DNT;0 to the site and its third parties
   c) I suggest not to include a case for finding out whether the URL
promise is still unchanged.
       If a site expands the list of third parties, it may require
polling via the Javascript API
Received on Tuesday, 22 May 2012 22:07:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:42 UTC