- From: David Singer via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 09 Aug 2012 22:34:57 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv25543
Modified Files:
tracking-dnt.html
Log Message:
Changes to the exception APIs section
file all the issues so they have numbers
recommend bypassing asking the user if the exception is already granted
different suggestion on how 1st parties track persistence of the exception
issue and section on querying the exception state
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.145
retrieving revision 1.146
diff -u -d -r1.145 -r1.146
--- tracking-dnt.html 8 Aug 2012 08:02:53 -0000 1.145
+++ tracking-dnt.html 9 Aug 2012 22:34:55 -0000 1.146
@@ -1196,7 +1196,7 @@
</section>
<section id='exceptions' class="option">
- <h2>User-Granted Exceptions</h2>
+ <h1>User-Granted Exceptions</h1>
<section id="exceptions-overview" class="informative">
<h2>Overview</h2>
@@ -1217,7 +1217,7 @@
</p>
<p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/144">ISSUE-144</a>: What constraints on user agents should be imposed for user/granted exceptions. <br/>
- <b>[OPEN]</b>
+ <b>[OPEN]</b> but mostly addressed in the proposal here.
</p>
</section>
@@ -1344,7 +1344,7 @@
</p>
<ul>
<li>First, the UA somehow confirms with the user that they agree
- to the grant of exception;</li>
+ to the grant of exception, if not already granted;</li>
<li>If they agree, then the UA adds to its local database one or
more site-pair duplets [document-origin, target]; one or other
of these may be a wild-card ("*");</li>
@@ -1372,14 +1372,14 @@
</li>
</ol>
<p class="issue">
- What is the effect of re-directs, when the source of the re-direct
+ <a href="https://www.w3.org/2011/tracking-protection/track/issues/158">Issue-158</a>: What is the effect of re-directs, when the source of the re-direct
would get a different DNT header than the target, using these
matching rules?<br />
<b>Proposal</b>: The re-direct is not relevant; each site gets the
DNT header controlled by the list of grants.
</p>
<p class="issue">
- This model does not support mashed-up content which is in turn
+ <a href="https://www.w3.org/2011/tracking-protection/track/issues/159">Issue-159</a>: This model does not support mashed-up content which is in turn
supported by ads; it's not clear how to distinguish between
embedded content which is embedding ads (and hence the top-level
domain stays the same) and embedded content that should start a
@@ -1387,7 +1387,23 @@
<b>Proposal</b>: For this version of the specification, we don't
address this corner case.
</p>
- <div class="note">
+ <p>
+ User-agents MUST handle each API request as a 'unit', granting
+ and maintaining it in its entirety, or not at all. That means
+ that a user-agent MUST NOT indicate to a site that a request for
+ targets {a, b, c} has been granted, and later remove only one or
+ two of {a, b, c} from its logical database of remembered grants.
+ This assures sites that the set of sites they need for
+ operational integrity is treated as a unit. Each separate call
+ to an API is a separate unit.
+ </p>
+ <p>
+ When a user-agent receives an API request for an exception that
+ already exists (i.e. the grant is recorded in its database), it SHOULD
+ bypass asking the user to confirm, and simply re-confirm the grant
+ to the caller.
+ </p>
+ <div class="note">
<p>
It is left up to individual user-agent implementations how to
determine and how and whether to store users' tracking
@@ -1407,16 +1423,6 @@
the top-level domain is asking for an exception for all
third-parties that are, or will be, embedded in it.
</p>
- <p>
- User-agents MUST handle each API request as a 'unit', granting
- and maintaining it in its entirety, or not at all. That means
- that a user-agent MUST NOT indicate to a site that a request for
- targets {a, b, c} has been granted, and later remove only one or
- two of {a, b, c} from its logical database of remembered grants.
- This assures sites that the set of sites they need for
- operational integrity is treated as a unit. Each separate call
- to an API is a separate unit.
- </p>
</div>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>: Different DNT values to signify existence of user-granted exception<br />
@@ -1425,11 +1431,15 @@
for that first party? (e.g. DNT:2 implies "I have Do Not Track
enabled but grant permissions to some third parties while browsing
this domain")<br />
- <b>Proposal</b>: No, this API provides client-side means for sites
- to request that information. Sites may also employ cookies to
- recall a user's past response. Finally, a site may add
- [self, self] to the database as part of its request, and it will
- then get DNT:0.
+ <b>Proposal</b>: A previous proposal was that it can add itself to the
+ list (i.e. an exception for [site, site]) and then it will get DNT:0,
+ but DNT:0 to a first party means something different (that it can pass
+ data to third parties, and tracking is permitted). It would be better to
+ have an indication in the DNT header that one or more site-specific
+ exceptions exist for the given target (i.e. that there is at least one
+ duplet in the database with target as its first host name), for example
+ "DNT:1E" where E means you are a first party with one or more
+ active exceptions.
</p>
</section>
</section>
@@ -1612,6 +1622,15 @@
</section>
</section>
+ <section id="exceptions-enquiry" >
+ <h2>Querying a host's exception status</h2>
+ <p class="issue"><a href="https://www.w3.org/2011/tracking-protection/track/issues/160">ISSUE-160</a>: Do we need an exception-query API?<br />
+ It might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context.<br />
+ <b>Proposal</b>: Specifically, an API QueryExceptionStatus() which examines the <b>document origin</b> of the script, the current <b>top-level domain</b> and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
+ </p>
+
+ </section>
+
<section id="exceptions-ui" class="informative">
<h2>User interface guidelines</h2>
Received on Thursday, 9 August 2012 22:34:58 UTC