- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 17 Apr 2013 09:24:44 -0700
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
I have not had time for the usual word diff, but here is a cvs diff
of the raw text.
....Roy
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.170
retrieving revision 1.198
diff -u -u -r1.170 -r1.198
--- tracking-dnt.html 29 Sep 2012 08:27:51 -0000 1.170
+++ tracking-dnt.html 17 Apr 2013 09:52:32 -0000 1.198
@@ -1,4 +1,3 @@
-<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<title>Tracking Preference Expression (DNT)</title>
@@ -39,7 +38,7 @@
honor this preference, both in the form of a machine-readable tracking
status resource at a well-known location and via a <q>Tk</q>
response header field, and a mechanism for allowing the user to approve
- site-specific exceptions to DNT as desired.
+ exceptions to DNT as desired.
</p>
</section>
@@ -198,8 +197,7 @@
</p>
<p>
The term <dfn>user-granted exception</dfn> is used when the user has
- permitted tracking by a given third party, usually in the form of a
- site-specific exception.
+ permitted tracking by a given third party.
</p>
<p>
A companion document, [[!TRACKING-COMPLIANCE]], defines many of the
@@ -220,9 +218,10 @@
all parties.
</p>
<p>
- Key to that notion of expression is that it MUST reflect the user's
- preference, not the choice of some vendor, institution, or
- network-imposed mechanism outside the user's control. The basic
+ Key to that notion of expression is that the signal sent MUST reflect the user's
+ preference, not the choice of some vendor, institution, site, or any
+ network-imposed mechanism outside the user's control; this applies
+ equally to both the general preference and exceptions. The basic
principle is that a tracking preference expression is only
transmitted when it reflects a deliberate choice by the user.
In the absence of user choice, there is no tracking preference
@@ -341,8 +340,8 @@
expressing a user's tracking preference via HTTP [[!HTTP11]].
</p>
<pre class="abnf">
-<dfn>DNT-field-name</dfn> = "DNT" ; case-insensitive
-<dfn>DNT-field-value</dfn> = ( "0" / "1" ) *DNT-extension ; case-sensitive
+<dfn>DNT-field-name</dfn> = "DNT"
+<dfn>DNT-field-value</dfn> = ( "0" / "1" ) *DNT-extension
<dfn>DNT-extension</dfn> = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash
</pre>
@@ -357,7 +356,7 @@
The DNT field-value sent by a user agent MUST begin with the
numeric character "1" (%x31) if a tracking preference is
<a>enabled</a>, the preference is for no tracking, and
- there is not a site-specific exception for the origin server
+ there is not an exception for the origin server
targeted by this request.
</p>
<p>
@@ -411,56 +410,33 @@
<p class="note">This document does not have any implied or specified
behavior for the user-agent treatment of cookies when DNT is enabled.
</p>
+ <p class="note">The HTTP specification [[!HTTP11]] permits multiple headers
+ with the same field-name only under restricted circumstances which do
+ not apply here; hence, at most one DNT header may be present in a valid
+ HTTP request.
+ </p>
+
</section>
<section id='js-dom'>
- <h3>JavaScript API to Detect Preference</h3>
-
- <p>
- A <a>doNotTrack</a> attribute on the <code>Navigator</code>
- interface [[!NAVIGATOR]] (e.g., the <code>window.navigator</code>
- object) is hereby defined as the means for expressing the user's
- general tracking preference to scripts running within a top-level
- page. A user agent MUST provide a <code>doNotTrack</code> attribute
- on the <code>Navigator</code> interface for each top-level page.
- </p>
- <dl class="idl" title='partial interface Navigator {
- readonly attribute DOMString doNotTrack;
- };'>
- <dt>readonly attribute DOMString doNotTrack</dt>
- <dd>
- When a tracking preference is <a>enabled</a>, the
- <code>doNotTrack</code> attribute for each top-level page MUST
- have the same string value that would be sent in a
+ <h3>JavaScript Property to Detect Preference</h3>
+ <p>
+ This property enables a site executing code in its own origin
+ to determine what DNT header would be sent to it in the current
+ context, taking into account the user's general preference (if
+ any) and any user-granted exceptions.</p>
+ <dl class="idl" title='[NoInterfaceObject] interface WindowDoNotTrack'>
+ <dt>attribute DOMString doNotTrack</dt>
+ <dd>
+ Returns the same string value that would be sent in a
<a>DNT-field-value</a> (<a href="#dnt-header-field"
- class="sectionRef"></a>) to an origin server that does not have
- any corresponding user-granted exceptions.
- When a tracking preference is <a>not enabled</a>, the
- <code>doNotTrack</code> attribute for each top-level page MUST
- have a value of <code>null</code>.
- </dd>
- </dl>
- <p>
- The <code>doNotTrack</code> attribute only provides the user's
- general tracking preference, independent of any user-granted
- exceptions or out-of-band consent. A script wishing to determine
- the specific tracking preference for a given document origin is
- expected to use the API in <a href="#exceptions-enquiry"
- class="sectionRef"></a>.
- </p>
- <p>
- A user agent MUST provide a <code>doNotTrack</code> attribute
- value that is consistent with the user's current tracking
- preference that would be expressed via the DNT header field.
- However, changes to the user's preference might occur between
- the time when the APIs are checked and an actual request is made.
- A server MUST treat the user's most recently received preference as
- authoritative.
- </p>
- <p class="issue" data-number="116" title="How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals?">
- <strong>[PENDING REVIEW]</strong>
- Updated text in this section.
- </p>
+ class="sectionRef"></a>) to a <strong>target</strong> that is the
+ document-origin of the <code>window</code>, in the
+ context of the current <strong>top-level origin</strong>. If no DNT
+ header would be sent (e.g. because a tracking preference is
+ <a>not enabled</a>) the value is <code>null</code>.
+ </dd>
+ </dl>
</section>
<section id='plug-ins'>
@@ -541,212 +517,211 @@
user to a request-specific tracking status resource applicable to
the current request.
</p>
-
</section>
<section id='tracking-status-value'>
<h3>Tracking Status Value</h3>
- <p>
- A <dfn>tracking status value</dfn> is a short notation for
- communicating how a designated resource conforms to the tracking
- protection protocol, as defined by this document and
- [[!TRACKING-COMPLIANCE]]. There is no form of negative response;
- i.e., an origin server that does not wish to claim conformance
- to this protocol would not supply a tracking status resource and
- would not send a Tk header field in responses.
- </p>
- <p>
- For a site-wide tracking status resource, the designated resource
- to which the tracking status applies is any resource on the same
- origin server. For a <a>Tk</a> response header field, the
- corresponding request target is the designated resource and
- remains so for any subsequent request-specific tracking status
- resource referred to by that field.
- </p>
- <p>
- All of the tracking status mechanisms use a common format for the
- tracking status value: a single character from a limited set.
- The meaning of each allowed character is defined in the following
- table.
- </p>
- <table class="simple">
- <tr>
- <th>status</th>
- <th>meaning</th>
- </tr>
- <tr><td><dfn>N</dfn></td>
- <td><strong>None</strong>: The designated resource does not
- perform tracking of any kind, not even for a <a>permitted use</a>,
- and does not make use of any data collected from tracking.</td>
- </tr>
- <tr><td><dfn>1</dfn></td>
- <td><strong>First party</strong>: The designated resource is
- designed for use within a first-party context and conforms to
- the requirements on a first party. If the designated resource
- is operated by an outsourced service provider, the service
- provider claims that it conforms to the requirements on a
- third party acting as a first party.</td>
- </tr>
- <tr><td><dfn>3</dfn></td>
- <td><strong>Third party</strong>: The designated resource is
- designed for use within a third-party context and conforms to
- the requirements on a third party.</td>
- </tr>
- <tr><td><dfn>X</dfn></td>
- <td><strong>Dynamic</strong>: The designated resource is
- designed for use in both first and third-party contexts and
- dynamically adjusts tracking status accordingly.
- If <code>X</code> is present in the site-wide tracking status,
- more information MUST be provided via the <a>Tk</a> response
- header field when accessing a designated resource.
- If <code>X</code> is present in the <a>Tk</a> header field,
- more information will be provided in a request-specific
- tracking status resource referred to by the <a>status-id</a>.
- An origin server MUST NOT send <code>X</code> as the
- tracking status value in the representation of a
- request-specific tracking status resource.</td>
- </tr>
- <tr><td><dfn>C</dfn></td>
- <td><strong>Consent</strong>: The designated resource believes
- it has received prior consent for tracking this user, user
- agent, or device, perhaps via some mechanism not defined by
- this specification, and that prior consent overrides the
- tracking preference expressed by this protocol.</td>
- </tr>
- <tr><td><dfn>U</dfn></td>
- <td><strong>Updated</strong>: The request resulted in a
- potential change to the tracking status applicable to this
- user, user agent, or device. A user agent that relies on a
- cached tracking status SHOULD update the cache entry with
- the current status by making a new request on the applicable
- tracking status resource. An origin server MUST NOT send
- <code>U</code> as a tracking status value anywhere other than
- a <a>Tk</a> header field that is in response to a
- state-changing request.</td>
- </tr>
- </table>
- <p>
- For the site-wide tracking status and Tk header field, the tracking
- status values <code><a>1</a></code> and <code><a>3</a></code>
- indicate how the designated resource is designed to conform, not
- the nature of the request. Hence, if a user agent is making a
- request in what appears to be a third-party context and the
- tracking status value indicates that the designated resource is
- designed only for first-party conformance, then either the context
- has been misunderstood (both are actually the same party) or the
- resource has been referenced incorrectly. For the request-specific
- tracking status resource, an indication of first or third party as
- the status value describes how the resource conformed to that
- specific request, and thus indicates both the nature of the request
- (as viewed by the origin server) and the applicable set of
- requirements to which the origin server claims to conform.
- </p>
- <p>
- The tracking status value is case sensitive, as defined formally
- by the following ABNF.
- </p>
- <pre class="abnf">
-<dfn>tracking-v</dfn> = "1" ; "1" — first-party
- / "3" ; "3" — third-party
- / %x43 ; "C" - consent
- / %x4E ; "N" - none
- / %x55 ; "U" - updated
- / %x58 ; "X" - dynamic
- </pre>
+ <section id='TSV-defn'>
+ <h4>Definition</h4>
- <p class="issue" data-number="137" title="Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)">
- <b>[PENDING REVIEW]</b> No, in practice there may be dozens of
- service providers on any given request. If the designated resource
- is operated by a service provider acting as a first party, then the
- responsible first party is identified by the policy link or the
- owner of the origin server domain. This satisfies the use case of
- distinguishing between a service provider acting for some other site
- and the same service provider acting on one of its own sites.
- </p>
- </section>
+ <p>
+ A <dfn>tracking status value</dfn> (TSV) is a short notation for
+ communicating how a designated resource conforms to the tracking
+ protection protocol, as defined by this document and
+ [[!TRACKING-COMPLIANCE]].
+ For a site-wide tracking status resource, the designated resource
+ to which the tracking status applies is any resource on the same
+ origin server. For a <a>Tk</a> response header field, the
+ corresponding request target is the designated resource and
+ remains so for any subsequent request-specific tracking status
+ resource referred to by that field.
+ </p>
+ <p>
+ The tracking status value is case sensitive, as defined formally
+ by the following ABNF.
+ </p>
+ <pre class="abnf">
+<dfn>TSV</dfn> = "1" ; "1" — first-party
+ / "3" ; "3" — third-party
+ / %x43 ; "C" - consent
+ / %x44 ; "D" - disregarding
+ / %x4E ; "N" - none
+ / %x55 ; "U" - updated
+ / %x58 ; "X" - dynamic
+ / ( "!" [testv] ) ; "!" - non-compliant
+
+<dfn>testv</dfn> = id-char
+ </pre>
- <section id='status-qualifier-value'>
- <h3>Tracking Status Qualifier Values</h3>
+ <p class="issue" data-number="137" title="Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)">
+ <b>[PENDING REVIEW]</b> No, in practice there may be dozens of
+ service providers on any given request. If the designated resource
+ is operated by a service provider acting as a first party, then
+ the responsible first party is identified by the
+ <code><a>controller</a></code> member or the owner of the origin
+ server domain. This satisfies the use case of distinguishing
+ between a service provider acting for some other site and the same
+ service provider acting on one of its own sites.
+ </p>
+ <p class="issue" data-number="161" title="Do we need a tracking status value for partial compliance or rejecting DNT?">
+ <b>[PENDING REVIEW]</b> See options below for the
+ <code><a>!</a></code> and <code><a>D</a></code> tracking status
+ values.
+ </p>
+ </section>
+ <section id='TSV-N'>
+ <h4>None (N)</h4>
<p>
- When present, the tracking status qualifier member's value
- consists of a string of characters indicating what permitted
- uses for tracking are being used.
- Multiple qualifiers can be provided.
+ A tracking status value of <dfn>N</dfn> means that the origin
+ server claims that the designated resource does not perform
+ tracking of any kind, not even for a <a>permitted use</a>,
+ and does not make use of any data collected from tracking.
</p>
- <p class="issue" data-number="136" title="Resolve dependencies of the
- TPE on the compliance specification">
- The list of qualifiers is intended to match one to one to the permitted uses
- identified by [[!TRACKING-COMPLIANCE]], using references to the
- definitions there. The list will then be updated accordingly.
- </p>
+ </section>
- <table class="simple">
- <tr><th>qualifier</th>
- <th>meaning</th>
- </tr>
- <tr><td>a</td>
- <td>Audit: Tracking is limited to that necessary for an
- external audit of the service context and the data
- collected is minimized accordingly.</td>
- </tr>
- <tr><td>c</td>
- <td>Ad frequency capping: Tracking is limited to frequency
- capping and the data collected is minimized accordingly.</td>
- </tr>
- <tr><td>f</td>
- <td>Fraud prevention: Tracking is limited to that necessary
- for preventing or investigating fraudulent behavior and
- security violations; the data collected is minimized
- accordingly.</td>
- </tr>
- <tr><td>l</td>
- <td>Local constraints: Tracking is limited to what is
- required by local law, rule, or regulation and the
- data collected is minimized accordingly.</td>
- </tr>
- <tr><td>r</td>
- <td>Referrals: Tracking is limited to collecting referral
- information and the data collected is minimized
- accordingly.</td>
- </tr>
- </table>
+ <section id='TSV-1'>
+ <h4>First Party (1)</h4>
<p>
- Qualifiers that indicate limitations on tracking correspond to
- the specific permitted uses in [[!TRACKING-COMPLIANCE]]. An
- origin server indicating one or more of those permitted uses
- also indicates that it conforms to the requirements associated
- with those permitted uses. Multiple limitation qualifiers mean
- that multiple permitted uses of tracking might be present and
- that each such use conforms to the associated requirements.
- All limitation qualifiers imply some form of tracking might
- be used and thus MUST NOT be provided with a tracking status
- value of <code>N</code> (not tracking).
- </p>
- <p>
- Future extensions to this protocol might define additional
- characters as qualifiers from the
- <code><a>ext-qualifier</a></code> set (consisting of the
- remaining unused lowercase letters, dot, dash, and underscore).
- Recipients SHOULD ignore extension qualifiers that they do not
- understand.
+ A tracking status value of <dfn>1</dfn> means that the origin
+ server claims that the designated resource is designed for use
+ only within a first-party context and conforms to the requirements
+ on a first party.
+ If the designated resource is operated by an outsourced service
+ provider, the service provider claims that it conforms to the
+ requirements on a third party acting as a first party.
+ </p>
+ <p>
+ For the site-wide tracking status and Tk header field, the tracking
+ status values <code>1</code> and <code>3</code>
+ indicate how the designated resource is designed to conform, not
+ the nature of the request. Hence, if a user agent is making a
+ request in what appears to be a third-party context and the
+ tracking status value indicates that the designated resource is
+ designed only for first-party conformance, then either the context
+ has been misunderstood (both are actually the same party) or the
+ resource has been referenced incorrectly.
+ </p>
+ <p>
+ For the request-specific tracking status resource, an indication
+ of first or third party as the status value describes how the
+ resource conformed to that specific request, and thus indicates
+ both the nature of the request (as viewed by the origin server)
+ and the applicable set of requirements to which the origin server
+ claims to conform.
</p>
+ </section>
+
+ <section id='TSV-3'>
+ <h4>Third Party (3)</h4>
<p>
- The tracking qualifier value is case sensitive, as defined formally
- by the following ABNF.
- </p>
- <pre class="abnf">
- <dfn>tracking-q</dfn> = tracking-q-v*
- <dfn>tracking-q-v</dfn> = %x61 ; "a" - audit
- / %x63 ; "c" — capping
- / %x66 ; "f" - fraud
- / %x6C ; "l" - local
- / %x72 ; "r" - referral
- </pre>
+ A tracking status value of <dfn>3</dfn> means that the origin
+ server claims that the designated resource is designed for use
+ within a third-party context and conforms to the requirements on a
+ third party.
+ </p>
+ </section>
+ <section id='TSV-X'>
+ <h4>Dynamic (X)</h4>
+ <p>
+ A tracking status value of <dfn>X</dfn> means that the origin
+ server claims that the designated resource is designed for use in
+ both first and third-party contexts and dynamically adjusts
+ tracking status accordingly.
+ </p>
+ <p>
+ If <code>X</code> is present in the site-wide tracking status,
+ more information MUST be provided via the <a>Tk</a> response
+ header field when accessing a designated resource.
+ If <code>X</code> is present in the <a>Tk</a> header field,
+ more information will be provided in a request-specific
+ tracking status resource referred to by the <a>status-id</a>.
+ An origin server MUST NOT send <code>X</code> as the
+ tracking status value in the representation of a
+ request-specific tracking status resource.
+ </p>
</section>
-
+
+ <section id='TSV-C'>
+ <h4>Consent (C)</h4>
+ <p>
+ A tracking status value of <dfn>C</dfn> means that the origin
+ server believes it has received prior consent for tracking this
+ user, user agent, or device, perhaps via some mechanism not
+ defined by this specification, and that prior consent overrides
+ the tracking preference expressed by this protocol.
+ </p>
+ </section>
+
+ <section id='TSV-D' class="option">
+ <h4>Disregarding (D)</h4>
+ <p>
+ A tracking status value of <dfn>D</dfn> means that the origin
+ server is unable or unwilling to respect a tracking preference
+ received from the requesting user agent. An origin server that
+ sends this tracking status value MUST detail within the server's
+ corresponding privacy policy the conditions under which a tracking
+ preference might be disregarded.
+ </p>
+ <p>
+ For example, an origin server might disregard the DNT field
+ received from specific user agents (or via specific network
+ intermediaries) that are deemed to be non-conforming, might be
+ collecting additional data from specific source network
+ locations due to prior security incidents, or might be
+ compelled to disregard certain DNT requests to comply with a
+ local law, regulation, or order.
+ </p>
+ </section>
+
+ <section id='TSV-U'>
+ <h4>Updated (U)</h4>
+ <p>
+ A tracking status value of <dfn>U</dfn> means that the request
+ resulted in a potential change to the tracking status applicable
+ to this user, user agent, or device. A user agent that relies on a
+ cached tracking status SHOULD update the cache entry with the
+ current status by making a new request on the applicable tracking
+ status resource.
+ </p>
+ <p>
+ An origin server MUST NOT send <code>U</code> as a tracking status
+ value anywhere other than a <a>Tk</a> header field that is in
+ response to a state-changing request.
+ </p>
+ </section>
+
+ <section id='TSV-!' class="option">
+ <h4>Non-compliant (!)</h4>
+ <p>
+ A tracking status value of <dfn>!</dfn> means that the origin
+ server is unable or unwilling to claim that the designated
+ resource conforms to the tracking protection protocol, but is
+ providing a tracking response for the sake of testing and
+ transparency.
+ </p>
+ <p>
+ The <code>!</code> value has been provided to ease testing and
+ deployment on production systems during the initial periods of
+ testing compliance and during adjustment periods due to future
+ protocol changes or shifting regulatory constraints. Note that
+ this value does not indicate that the DNT signal will be ignored,
+ nor that tracking will occur as a result of accessing the
+ designated resource, but rather that the site makes no claim to
+ conformance at this time.
+ </p>
+ <p>
+ This <code>!</code> value MAY be followed by an optional
+ <a>testv</a> character in order to communicate further information
+ for testing, such as what tracking status the server intends to
+ deploy for the designated resource at some point in the future,
+ but that cannot be relied upon as an indication of conformance.
+ </p>
+ </section>
+ </section>
+
<section id='response-header-field'>
<h3>Tk Header Field for HTTP Responses</h3>
@@ -761,15 +736,13 @@
interactive change to the tracking status.
</p>
<pre class="abnf">
-<dfn>Tk-field-name</dfn> = "Tk" ; case-insensitive
-<dfn>Tk-field-value</dfn> = tracking-v [tracking-q] [ ";" status-id ]
+<dfn>Tk-field-name</dfn> = "Tk"
+<dfn>Tk-field-value</dfn> = TSV [ ";" status-id ]
</pre>
<p>
The Tk field-value begins with a tracking status value
(<a href="#tracking-status-value" class="sectionRef"></a>),
- optionally followed by one or more tracking qualifiers
- (<a href="#status-qualifier-value" class="sectionRef"></a>), and then
- optionally a semicolon and a <code>status-id</code>
+ optionally followed by a semicolon and a <code>status-id</code>
that refers to a request-specific tracking status resource
(<a href="#referring-status-id" class="sectionRef"></a>).
</p>
@@ -778,15 +751,6 @@
be tracking would look like:
</p>
<pre class="example">Tk: N</pre>
- <p>
- whereas a <a>Tk</a> header field for a resource that might perform
- tracking (though not necessarily for every request) and conforms
- to the third-party requirements of [[!TRACKING-COMPLIANCE]], while
- claiming the audit exception, would
- look like:
- </p>
- <pre class="example">Tk: 3a</pre>
-
</section>
<section id='referring-status-id'>
@@ -802,7 +766,7 @@
status resource applies to the current request.
</p>
<pre class="abnf">
-<dfn>status-id</dfn> = 1*id-char ; case-sensitive
+<dfn>status-id</dfn> = 1*id-char
<dfn>id-char</dfn> = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
</pre>
<p>
@@ -820,6 +784,7 @@
If a Tk field-value has a tracking status value of
<code><a>X</a></code> (dynamic), then a
<code><a>status-id</a></code> MUST be included in the field-value.
+ The status-id is case-sensitive.
</p>
</section>
@@ -830,7 +795,7 @@
the scope of this specification, that have the effect of asking
for and obtaining prior consent for tracking, or for modifying
prior indications of consent. For example, the tracking status
- resource's status-object defines a <code><a>control</a></code>
+ resource's status-object defines an <code><a>edit</a></code>
member that can refer to such a mechanism. Although such
out-of-band mechanisms are not defined by this specification,
their presence might influence the tracking status object's
@@ -860,11 +825,11 @@
An origin server MUST provide a <dfn>site-wide tracking status
resource</dfn> at the well-known identifier [[RFC5785]]
</p>
- <pre>/.well-known/dnt</pre>
+ <pre>/.well-known/dnt/</pre>
<p>
(relative to the URI of that origin server) for obtaining
information about the potential tracking behavior of resources
- provided by that origin server. A tracking status resource MAY be
+ provided by that origin server. A tracking status resource can be
used for verification of DNT support, as described in
<a href="#using-tracking-status" class="sectionRef"></a>.
</p>
@@ -876,7 +841,7 @@
leads to such a representation.
A user agent MAY consider failure to provide access to such a
representation equivalent to the origin server not implementing
- this protocol. The representation MAY be cached, as described
+ this protocol. The representation can be cached, as described
in <a href="#status-caching" class="sectionRef"></a>.
</p>
</section>
@@ -898,7 +863,7 @@
The <dfn>tracking status resource space</dfn> is defined by the
following URI Template [[URI-TEMPLATE]]:
</p>
- <pre>/.well-known/dnt{/status-id}</pre>
+ <pre>/.well-known/dnt/{+status-id}</pre>
<p>
where the value of <code>status-id</code> is a string of URI-safe
characters provided by a <a>Tk</a> field-value in response to a
@@ -919,10 +884,10 @@
<section id='status-representation'>
<h3>Representation</h3>
<p>
- The representation of a tracking status resource SHALL be provided
- in the "application/json" format [[!RFC4627]] and MUST conform to
- the ABNF for <a>status-object</a> (except that the members within
- each member-list MAY be provided in any order).
+ An origin server MUST provide a representation of each tracking
+ status resource in the JSON format [[!RFC4627]] that conforms to
+ the ABNF for <code><a>status-object</a></code> (except that the
+ members within each member-list MAY be provided in any order).
</p>
<p>
The following example tracking status representation
@@ -932,6 +897,8 @@
<pre class="example">
{
"tracking": "1",
+ "qualifiers": "afc",
+ "controller": ["https://www.example.com/privacy"],
"same-party": [
"example.com",
"example_vids.net",
@@ -943,36 +910,37 @@
"audit": [
"http://auditor.example.org/727073"
],
- "policy": "/tracking.html",
- "control": "http://example.com/your/data"
+ "policy": "/privacy.html#tracking",
+ "edit": "http://example.com/your/data"
}
</pre>
<p>
A tracking status representation consists of a single
- <a>status-object</a> containing members that describe the
- tracking status applicable to the designated resource.
+ <code><a>status-object</a></code> containing members that describe
+ the tracking status applicable to the designated resource.
</p>
<pre class="abnf">
<dfn>status-object</dfn> = begin-object member-list end-object
-<dfn>member-list</dfn> = tracking ns tracking-v [tracking-q]
+<dfn>member-list</dfn> = tracking ns tracking-v
+ [ vs qualifiers ns qualifiers-v ]
+ [ vs controller ns controller-v ]
[ vs same-party ns same-party-v ]
[ vs third-party ns third-party-v ]
[ vs audit ns audit-v ]
[ vs policy ns policy-v ]
- [ vs control ns control-v ]
+ [ vs edit ns edit-v ]
*( vs extension )
</pre>
<p>
- A <a>status-object</a> MUST have a member named
- <code><a>tracking</a></code> that contains a single character
- tracking status value
- (<a href="#tracking-status-value" class="sectionRef"></a>),
- optionally followed by one or more tracking qualifiers
- (<a href="#status-qualifier-value" class="sectionRef"></a>) .
+ A <code><a>status-object</a></code> always has a member named
+ <code><a>tracking</a></code> with a string value that consists of
+ the tracking status value applicable to the designated resource
+ (<a href="#tracking-status-value" class="sectionRef"></a>).
</p>
<pre class="abnf">
<dfn>tracking</dfn> = %x22 "tracking" %x22
+<dfn>tracking-v</dfn> = %x22 TSV %x22
</pre>
<p>
For example, the following demonstrates a minimal tracking status
@@ -983,11 +951,108 @@
{"tracking": "N"}
</pre>
<p>
+ An origin server MAY send a <code><a>status-object</a></code>
+ member named <code><a>qualifiers</a></code> with a string value
+ containing a sequence of case sensitive characters corresponding
+ to each of the permitted uses (as defined in
+ [[!TRACKING-COMPLIANCE]]) that might be in use for the designated
+ resource. The purpose of this field is to provide additional
+ transparency where desired.
+ </p>
+ <table class="simple">
+ <tr><th>qualifier</th>
+ <th>meaning</th>
+ </tr>
+ <tr><td>a</td>
+ <td>Audit: Tracking is limited to that necessary for an
+ external audit of the service context and the data
+ collected is minimized accordingly.</td>
+ </tr>
+ <tr><td>c</td>
+ <td>Ad frequency capping: Tracking is limited to frequency
+ capping and the data collected is minimized accordingly.</td>
+ </tr>
+ <tr><td>f</td>
+ <td>Fraud prevention: Tracking is limited to that necessary
+ for preventing or investigating fraudulent behavior and
+ security violations; the data collected is minimized
+ accordingly.</td>
+ </tr>
+ <tr><td>l</td>
+ <td>Local constraints: Tracking is limited to what is
+ required by local law, rule, or regulation and the
+ data collected is minimized accordingly.</td>
+ </tr>
+ <tr><td>r</td>
+ <td>Referrals: Tracking is limited to collecting referral
+ information and the data collected is minimized
+ accordingly.</td>
+ </tr>
+ </table>
+ <p>
+ Multiple qualifiers mean that multiple permitted uses of tracking
+ might be present and that each such use conforms to the associated
+ requirements. All qualifiers imply some form of tracking might be
+ used and thus MUST NOT be provided with a tracking status value of
+ <code>N</code> (not tracking).
+ </p>
+ <pre class="abnf">
+<dfn>qualifiers</dfn> = %x22 "qualifiers" %x22
+<dfn>qualifiers-v</dfn> = %x22 0*5qualifier %x22
+<dfn>qualifier</dfn> = %x61 ; "a" - audit
+ / %x63 ; "c" - capping
+ / %x66 ; "f" - fraud
+ / %x6C ; "l" - local
+ / %x72 ; "r" - referral
+ </pre>
+ <p class="issue" data-number="136" title="Resolve dependencies of the TPE on the compliance specification">
+ The list of qualifiers is intended to match one to one to the permitted uses
+ identified by [[!TRACKING-COMPLIANCE]], using references to the
+ definitions there. The list will then be updated accordingly.
+ </p>
+ <p>
+ An origin server MAY send a member named
+ <code><a>controller</a></code> with an array value containing
+ a list of URI references indirectly identifying the party or
+ set of parties that claims to be the responsible data controller
+ for personal data collected via the designated resource. An origin
+ server MUST send a <code><a>controller</a></code> member if the
+ responsible data controller does not own the designated resource's
+ domain name.
+ </p>
+ <p>
+ An origin server that does not send <code><a>controller</a></code>
+ is implying that its domain owner is the sole data controller;
+ information about the data controller ought to be found on the
+ designated resource's site root page, or by way of a clearly
+ indicated link from that page (i.e., no controller member is
+ considered equivalent to: <code>"controller":["/"]</code>).
+ </p>
+ <p>
+ If the designated resource has joint data controllers
+ (i.e., multiple parties have independent control over the
+ collected data), the origin server MUST send a
+ <code><a>controller</a></code> member that contains a reference
+ for each data controller.
+ </p>
+ <p>
+ Each URI reference provided in <code><a>controller</a></code>
+ MUST refer to a resource that, if a retrieval action is performed
+ on that URI, would provide the user with information regarding
+ (at a minimum) the identity of the corresponding party and
+ its data collection practices.
+ </p>
+ <pre class="abnf">
+<dfn>controller</dfn> = %x22 "controller" %x22
+<dfn>controller-v</dfn> = array-of-strings
+ </pre>
+ <p>
An OPTIONAL member named <code><a>same-party</a></code> MAY be
provided with an array value containing a list of domain names
that the origin server claims are the same party, to the extent
they are referenced by the designated resource, since all data
- collected via those references share the same data controller.
+ collected via those references share the same data controller as
+ the designated resource.
</p>
<pre class="abnf">
<dfn>same-party</dfn> = %x22 "same-party" %x22
@@ -1007,7 +1072,7 @@
<p>
An OPTIONAL member named <code><a>audit</a></code> MAY be
provided with an array value containing a list of URI references
- to external audits of the designated resource's tracking policy
+ to external audits of the designated resource's privacy policy
and tracking behavior in compliance with this protocol.
Preferably, the audit references are to resources that describe
the auditor and the results of that audit; however, if such a
@@ -1021,35 +1086,33 @@
<p>
An OPTIONAL member named <code><a>policy</a></code> MAY be
provided with a string value containing a URI-reference to a
- human-readable document that describes the tracking policy for
- the designated resource.
+ human-readable document that describes the relevant privacy policy
+ for the designated resource.
The content of such a policy document is beyond the
scope of this protocol and only supplemental to what is described
- by this machine-readable tracking status representation.
+ in the machine-readable tracking status representation.
+ If no <code><a>policy</a></code> member is provided, this
+ information might be obtained via the links provided in
+ <code><a>controller</a></code>.
</p>
<pre class="abnf">
<dfn>policy</dfn> = %x22 "policy" %x22
<dfn>policy-v</dfn> = string ; URI-reference
</pre>
<p>
- If the tracking status value is <code>1</code> and the designated
- resource is being operated by an outsourced service provider on
- behalf of a first party, the origin server MUST identify the
- responsible first party via the domain of the policy URI, if
- present, or by the domain owner of the origin server.
- If no policy URI is provided and the origin server domain is
- owned by the service provider, then the service provider is the
- first party.
- </p>
- <p>
- An OPTIONAL member named <code><a>control</a></code> MAY be
+ An OPTIONAL member named <code><a>edit</a></code> MAY be
provided with a string value containing a URI-reference to a
resource for giving the user control over personal data collected
by the designated resource (and possibly other resources);
- a <code><a>control</a></code> member SHOULD be provided if the
+ an <code><a>edit</a></code> member SHOULD be provided if the
tracking status value indicates prior consent
(<code><a>C</a></code>).
- Such a control resource might include the ability to review
+ If no <code><a>edit</a></code> member is provided, this
+ information might be obtained via the links provided in
+ <code><a>controller</a></code> or <code><a>policy</a></code>.
+ </p>
+ <p>
+ An edit resource might include the ability to review
past data collected, delete some or all of the data, provide
additional data (if desired), or <q>opt-in</q>, <q>opt-out</q>,
or otherwise modify an out-of-band consent status regarding
@@ -1059,14 +1122,14 @@
beyond the scope of this protocol.
</p>
<pre class="abnf">
-<dfn>control</dfn> = %x22 "control" %x22
-<dfn>control-v</dfn> = string ; URI-reference
+<dfn>edit</dfn> = %x22 "edit" %x22
+<dfn>edit-v</dfn> = string ; URI-reference
</pre>
<p>
Additional <code><a>extension</a></code> members MAY be provided
- in the <a>status-object</a> to support future enhancements to
- this protocol. A user agent SHOULD ignore extension members
- that it does not recognize.
+ in the <code><a>status-object</a></code> to support future
+ enhancements to this protocol. A user agent SHOULD ignore
+ extension members that it does not recognize.
</p>
<pre class="abnf">
<dfn>extension</dfn> = object
@@ -1097,9 +1160,20 @@
{
"tracking": "3",
"policy": "/privacy.html",
- "control": "/your/data",
+ "edit": "/your/data",
}
</pre>
+ <p class="issue" data-number="164" title="To what extent should the same-party attribute of tracking status resource be required?">
+ 3 Alternatives - text is needed:<br/>
+ (A) Current draft: Resource is optional<br/>
+ (B) Alternative proposal 1: If multiple domains on a page belong to the
+ same party, then this fact SHOULD be declared using the
+ same-party attribute<br/>
+ (C) Alternative proposal 2: State that user agents MAY assume that
+ additional elements that are hosted under a different URL and occur
+ on a page and declare "intended for 1st party use" are malicious unless
+ this URL is listed in the "same-party" attribute
+ </p>
</section>
<section id='status-checks-not-tracked'>
@@ -1139,7 +1213,8 @@
at which the service's tracking behavior might increase. For
example, if the tracking status response is set to expire in seven
days, then the earliest point in time that the service's tracking
- behavior can be increased is seven days after the policy has been
+ behavior can be increased is seven days after the tracking status
+ representation has been
updated to reflect the new behavior, since old copies might
persist in caches until the expiration is triggered. A service's
tracking behavior can be reduced at any time, with or without a
@@ -1210,11 +1285,9 @@
<section id='using-deployment'>
<h4>Discovering Deployment</h4>
<p>
- The presence of a site-wide tracking status representation is a
- claim that the service conforms to this protocol for a given user
- agent. Hence, deployment of this protocol for a given service can
+ Deployment of this protocol for a given service can
be discovered by making a retrieval request on the site-wide
- tracking resource <q><code>/.well-known/dnt</code></q> relative
+ tracking resource <q><code>/.well-known/dnt/</code></q> relative
to the service URI.
</p>
<p>
@@ -1241,16 +1314,16 @@
A user agent MAY check the tracking status for a designated
resource by first making a retrieval request for the site-wide
tracking status representation, as described above, and then
- parsing the representation as JSON to extract the Javascript
- <a>status-object</a>.
+ parsing the representation as JSON to extract the
+ <code><a>status-object</a></code>.
If retrieval is unsuccessful or parsing results in a syntax error,
the user agent SHOULD consider the site to be non-conformant with
this protocol.
</p>
<p>
- The <a>status-object</a> is supposed to have a member named
- <code><a>tracking</a></code> containing the tracking status value.
- The meaning of each tracking status value is defined in
+ The <code><a>status-object</a></code> is supposed to have a member
+ named <code><a>tracking</a></code> containing the tracking status
+ value. The meaning of each tracking status value is defined in
<a href="#tracking-status-value" class="sectionRef"></a>.
</p>
<p>
@@ -1276,22 +1349,16 @@
<h2>Overview</h2>
<p>
User-granted exceptions to Do Not Track, including site-specific
- exceptions, are managed by the user agent. A resource should rely on
+ exceptions, are agreed between the site and the user, and stored
+ by the user agent. A resource should rely on
the DNT header it receives to determine the user's preference for
tracking with respect to that particular request. An API is provided
so that sites may request and check the status of exceptions for
tracking.
</p>
- <p>
- We anticipate that many user-agents might provide a prompt to users
- when this API is used, or to store exceptions. Questions of user
- interface specifics — for granting, configuring, storing,
- syncing and revoking exceptions — are explicitly left open to
- implementers.
- </p>
<p class="issue" data-number="144" title="What constraints on user agents should be imposed for user/granted exceptions">
- <b>[OPEN]</b> but mostly addressed in the proposal here.
+ <b>[PENDING REVIEW]</b> but mostly addressed in the proposal here.
</p>
</section>
@@ -1321,7 +1388,7 @@
between a first-party publisher and its third parties.</li>
</ul>
<p>
- When asking for a site-specific exception, the top-level domain
+ When asking for a site-specific exception, the top-level origin
making the request may be making some implicit or explicit claims as
to the actions and behavior of its third parties; for this reason,
it might want to establish exceptions for only those for which it is
@@ -1334,16 +1401,64 @@
</p>
<p>
There are some cases in which a user may desire a site to be allowed
- to track them on any top-level domain. An API is provided so that
+ to track them on any top-level origin. An API is provided so that
the site and the user may establish such a web-wide exception.
</p>
</section>
<section id='exception-model'>
<h2>Exception model</h2>
-
<section>
- <h3>Introduction</h3>
+ <h3>User Interaction</h3>
+ <p>
+ The call to store an exception MUST reflect the user's intention to grant
+ an exception, at the time of the call. This intention MUST be determined by
+ the site prior to each call to store an exception, at the time of
+ the call. (This allows
+ the user to change their mind, and delete a stored exception, which might
+ then trigger the site to explain, and ask for, the exception again). It is
+ the responsibility solely of the site making the call to determine that
+ a call to record an exception reflects the user's informed consent at the
+ time of the call.
+ </p>
+
+ <p class="issue" data-number="194" title="How should we ensure consent of users for DNT inputs?">
+ <b>[OPEN]</b> We agree that exceptions should reflect user consent and that this needs to be ensured before a site is permitted to register an exception. There is concern that the language above is insufficient to guarantee this desire. Potential language that is acceptable by the whole group is still under discussion.
+ </p>
+ <p>
+ Sites MAY ask for an exception, and have it stored, even when the user's
+ general preference is not <a>enabled</a>.
+ (This permits recording a permission
+ to allow tracking in jurisdictions where such permission cannot be
+ assumed – see <a href="#exceptions-no-js" class="sectionRef"></a>.)
+ </p>
+ <p>
+ The user-agent MAY provide interfaces to the user:
+ <ul>
+ <li>To indicate that a call to store an exception has just been made;
+ <li>To allow the user to confirm a user-granted exception prior to
+ storage;
+ <li>To indicate that one or more exceptions exist for the current
+ top-level origin;
+ <li>To indicate that one or more exceptions exist for sites
+ incorporated into the current page;
+ <li>To allow the user to see and possibly revoke stored exceptions;
+ <li>Other aspects of the exception mechanism, as desired.
+ </ul>
+ There is no required user interface for the user agent;
+ user agents MAY choose to provide no user interface regarding
+ user-granted exceptions.
+ </p>
+ <p class="note">
+ The requirement for the site to determine the user's intention is new;
+ previously the site was required to inform, but the final
+ determination of intention was the responsibility of the UA. This
+ version removes that split of user-determination, and leaves it
+ solely with the site.
+ </p>
+ </section>
+ <section>
+ <h3>Processing Model</h3>
<p>
This section describes the effect of the APIs in terms of a
logical processing model; this model describes the behavior, but
@@ -1358,13 +1473,13 @@
specification, we define three terms:
</p>
<ul>
- <li><strong>Top-Level Domain (TLD)</strong> is the domain name
+ <li><strong>top-level origin</strong> is the domain name
of the top-level document origin of this DOM: essentially the
fully qualified domain name in the address bar.</li>
<li>A <strong>target</strong> site is a domain name which is the
target of an HTTP request, and which may be an origin for
embedded resources on <strong>the indicated top-level
- domain</strong>.</li>
+ origin</strong>.</li>
<li>The <strong>document origin</strong> of a script is the domain
of origin of the document that caused that script to be loaded
(not necessarily the same as the origin of the script
@@ -1376,13 +1491,13 @@
references the resources
<code>http://exnews.analytico.net/1x1.gif</code> and
<code>http://widgets.exsocial.org/good-job-button.js</code>,
- <strong>the top-level domain</strong> is <code>web.exnews.com</code>;
+ <strong>the top-level origin</strong> is <code>web.exnews.com</code>;
<code>exnews.analytico.net</code> and
<code>widgets.exsocial.org</code> are both
<strong>targets</strong>.
</p>
<p class="issue" data-number="112" title="How are sub-domains handled for site-specific exceptions?">
- <b>[PENDING REVIEW]</b> Should a request for a tracking exception
+ <b>[OPEN]</b> Should a request for a tracking exception
apply to all subdomains of the first party making the request? Or
should a first party explicitly list the subdomains that it's
asking for? Similarly, should third-party subdomains be allowed
@@ -1403,7 +1518,7 @@
sent in a given HTTP request include:
</p>
<ul>
- <li>The <strong>top-level domain</strong> of the current context;</li>
+ <li>The <strong>top-level origin</strong> of the current context;</li>
<li>The <strong>target</strong> of the HTTP request.</li>
</ul>
<p class="note">
@@ -1414,47 +1529,33 @@
will not change the DNT header it sends them.
</p>
<p>
- The calls cause the following steps to occur:
+ The calls cause the following steps to occur (subject to user
+ confirmation of the exception, if the user-agent asks for it):
</p>
<ul>
- <li>First, the UA somehow confirms with the user that they agree
- to the grant of exception, if not already granted;</li>
- <li>If they agree, then the UA adds to its local database one or
+ <li>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>
- <li>While the user is browsing a given site (top-level domain),
+ <li>While the user is browsing a given site (top-level origin),
and a DNT header is to be sent to a target domain, if the duplet
- [top-level domain, target domain] matches any duplet in the
+ [top-level origin, target domain] matches any duplet in the
database, then a DNT:0 header is sent, otherwise DNT:1 is
sent.</li>
</ul>
+ <p>In addition, responses to the JavaScript API indicated should be consistent
+ with this user preference (see below).</p>
+
<p class="note">
- Note that a site may record no that it has previously asked for, and been
- denied, an exception, if it wishes to avoid repeatedly asking the user
- for an exception.
- </p>
- </section>
+ The prior version of this required that the UA "somehow confirms with the
+ user that they agree to the grant of exception, if not already granted"
+ </p>
+
- <section id='exception-use-browsers'>
- <h3>Exception use by browsers</h3>
- <p>
- If a user agrees to allow tracking by a <strong>target</strong> on
- the <strong>top-level domain</strong>, this should result in two
- user-agent behaviors:
- </p>
- <ol>
- <li>If requests to the <strong>target</strong> for resources that
- are part of the DOM for pages on <strong>top-level domain</strong>
- include a DNT header, that header MUST be DNT:0.</li>
- <li>Responses to the JavaScript API indicated should be consistent
- with this user preference (see below).
- </li>
- </ol>
<p class="issue" data-number="159" title="How do we allow sites that mash-in ad-supported content to maintain their own trusted third parties?">
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
+ origin stays the same) and embedded content that should start a
new context.<br />
<b>Proposal</b>: For this version of the specification, we don't
address this corner case.
@@ -1463,18 +1564,12 @@
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
+ targets {a, b, c} exists in the database, 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
@@ -1484,35 +1579,41 @@
<p>
When an explicit list of domains is provided through the API,
their names might mean little to the user. The user might, for
- example, be told that such-and-such top-level domain is asking
- for an exception for a specific set of sites, rather than
- listing them by name; or the user-agent may decide to ask the
- user for a site-wide exception, effectively ignoring the list of
+ example, be told that there is a stored exception for a specific set
+ of sites on such-and-such top-level origin, rather than listing them
+ by name; or the user-agent may decide to store, and show to the user,
+ a site-wide exception, effectively ignoring the list of
domain names, if supplied.
</p>
<p>
- Conversely, if a wild-card is used, the user may be told that
- the top-level domain is asking for an exception for all
- third-parties that are, or will be, embedded in it.
+ Conversely, if a wild-card is used, the user may be told that there is
+ a stored exception for all third-parties that are, or will be, embedded
+ on the indicated the top-level origin.
</p>
</div>
- <p class="issue" data-number="111" title="Different DNT values to signify existence of user-granted exception">
- <b>[POSTPONED]</b> Should the user agent send a different DNT
- value to a first party site if there exist user-granted exceptions
- 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>: 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>
+ <p class="issue" data-number="151" title="User Agent Requirement: Be able to handle an exception request">
+ <b>[OPEN]</b> There is software that in just a few lines of code
+ just spawn DNT;1 or DNT;0 headers regardless of user's will. A
+ requirement on the user agent that they can handle the full
+ exception mechanism will allow to discard compliance statements by
+ those agents. It will
+ also allow also the site to test for conformance by requiring an
+ exception. In case the UA does not react on an exception request,
+ the server could ignore DNT signals from that UA. It would allow
+ thus testing from the horizon of the site without wild guessing;<br/>
+ However, there is no practical difference between a UA that hard-wires
+ 'no' to all exception requests, and a UA that does not implement the
+ calls.
+ </p>
+ <p class="issue" data-number="187" title="What is the right approach to exception handling?">
+ <b>[PENDING REVIEW]</b><br/>OLD: Site asks user agent for exception; user
+ agent asks user and responds (UA is responsible to ensure that
+ exceptions reflect user preferences)<br/>
+ NEW: Site asks user for their preference and stores this in user
+ agent. User agent may double-check that this indeed matches preference
+ but is not obliged to do so.
+ </p>
</section>
</section>
@@ -1520,92 +1621,61 @@
<h2>JavaScript API for Site-specific Exceptions</h2>
<section id="exceptions-javascript-api-rqst">
- <h3>API to request site-specific exceptions</h3>
+ <h3>API to Request a Site-specific Exception</h3>
- <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>void requestSiteSpecificTrackingException (
- in TrackingResponseCallback callback,
- optional sequence<DOMString> arrayOfDomainStrings,
- optional siteName,
- optional explanationString,
- optional detailURI)
+ <dl class="idl" title='partial interface Navigator'>
+ <dt>void storeSiteSpecificTrackingException (
+ StoreSiteSpecificExceptionPropertyBag properties)
</dt>
<dd>
- Called by a page to request or confirm a user-granted tracking
+ Called by a page to store a site-specific tracking
exception.
</dd>
</dl>
-
- <dl class="idl" title='[Callback, NoInterfaceObject] interface TrackingResponseCallback'>
- <dt>void handleEvent(in integer granted)</dt>
- <dd>
- The callback is called by the user agent to indicate the user's
- response.
- </dd>
+ <dl class="idl" title="dictionary StoreExceptionPropertyBag">
+ <dt>DOMString? domain</dt>
+ <dd>Cookie-like domain string to which the exception applies.</dd>
+ <dt>DOMString? siteName</dt>
+ <dd>A user-readable string for the name of the top-level origin.</dd>
+ <dt>DOMString? explanationString</dt>
+ <dd>A short explanation of the request.</dd>
+ <dt>DOMString? detailURI</dt>
+ <dd>A location at which further information about this request can be found.</dd>
</dl>
+ <dl class="idl" title="dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag">
+ <dt>sequence<DOMString> arrayOfDomainStrings</dt>
+ <dd>A JavaScript array of strings.</dd>
+ </dl>
+
<p>
- The <code>requestSiteSpecificTrackingException</code> method takes
- one mandatory argument:
+ The <code>storeSiteSpecificTrackingException</code> method takes
+ a dictionary argument of type <a>StoreSiteSpecificExceptionPropertyBag</a> that allows optional information to be provided.
</p>
- <ul>
- <li><code>callback</code>, a method that will be called when the
- request is complete.</li>
- </ul>
- <p>
- It also takes four optional arguments:
- </p>
- <ul>
- <li><code>arrayOfDomainStrings</code>, a JavaScript array of
- strings,</li>
- <li><code>siteName</code>, a user-readable string for the
- name of the top-level domain,</li>
- <li><code>explanationString</code>, a short explanation of the
- request, and</li>
- <li><code>detailURI</code>, a location at which further
- information about this request can be found.</li>
- </ul>
<p>
If the request does not include the
<code>arrayOfDomainStrings</code>, then this request is for a
site-wide exception. Otherwise each string in
<code>arrayOfDomainStrings</code> specifies a
<strong>target</strong>. When called,
- <code>requestSiteSpecificTrackingException</code> MUST return
- immediately, then asynchronously determine whether the user grants
- the requested exception(s).
+ <code>storeSiteSpecificTrackingException</code> MUST return
+ immediately.
</p>
<p>
If the list <code>arrayOfDomainStrings</code> is supplied, the
- user-agent MAY choose to ask the user to grant a site-wide
- exception. If it does so, and the user agrees, it MUST indicate
- this in the response callback.
+ user-agent MAY choose to store a site-wide
+ exception. If it does so it MUST indicate
+ this in the return value.
</p>
<p>
- The execution of this API and the use of the resulting permission
+ If <code>domain</code> is not specified or is null or empty then
+ the execution of this API and the use of the resulting permission
(if granted) use the 'implicit' parameter, when the API is called,
the <strong>document origin</strong>. This forms the first part of
the duplet in the logical model, and hence in operation will be
- compared with the <strong>top-level domain</strong>.
- </p>
- <p>
- The <code>granted</code> parameter passed to the callback is the
- user's response; The response
+ compared with the <strong>top-level origin</strong>.
</p>
- <ul>
- <li><code>0</code> indicates that user does not grant the
- exception on <strong>top-level domain</strong> for the indicated
- <strong>target</strong>s.</li>
- <li><code>1</code> indicates that the request was for specific
- <strong>target</strong>s and the the user grants an exception on
- <strong>top-level domain</strong> for those specific
- <strong>target</strong>s.</li>
- <li><code>2</code> indicates the user grants a site-wide exception
- on <strong>top-level domain</strong> for all
- <strong>target</strong>s; the request may have been for
- specific <strong>target</strong>s or for a site-wide exception.</li>
- </ul>
<p>
- If permission is granted for an explicit list, then the set of
+ If permission is stored for an explicit list, then the set of
duplets (one per target):
</p>
<pre>[document-origin, target]</pre>
@@ -1613,46 +1683,187 @@
is added to the database of remembered grants.
</p>
<p>
- If permission is granted for a site-wide exception, then the
- duplets:
+ If permission is stored for a site-wide exception, then the
+ duplet:
</p>
<pre>[document-origin, * ]</pre>
<p>
is added to the database of remembered grants.
</p>
<p>
- A particular response to the API — like a DNT response
- header — is only valid immediately, and users' preferences
- may change.
+ If <code>domain</code> is supplied and not empty then it is treated
+ in the same way as the domain parameter to cookies and allows setting
+ for subdomains. The <code>domain</code> argument can be set to
+ fully-qualified right-hand segment of the document host name, up to
+ one level below TLD.
+ </p>
+
+ <p class="note">For example, <em>www.foo.bar.example.com</em> may set the
+ domain parameter as as <code>"bar.example.com"</code> or
+ <code>"example.com"</code>, but not to <code>"something.else.example.com"</code>
+ or <code>"com"</code>.
</p>
+
+ <p>If the <code>domain</code> argument is not permitted by following the
+ cookie domain rules (e.g. not a right-hand match or is a TLD) then
+ a SYNTAX_ERR exception should be thrown.
+ </p>
+
+ <p>
+ If permission is stored for an explicit list, then the set of
+ duplets (one per target):
+ </p>
+ <pre>[*.domain, target]</pre>
<p>
- A user agent MAY use an interactive method to ask the user about
- their preferences, so sites SHOULD NOT assume that the callback
- function will be called immediately.
+ is added to the database of remembered grants.
+ </p>
+ <p>
+ If permission is stored for a site-wide exception, then the
+ duplet:
+ </p>
+ <pre>[*.domain, * ]</pre>
+ <p>
+ is added to the database of remembered grants.
+ </p>
+ <p>Here <code>*.domain</code> indicates that a wildcard match will be performed
+ against the domain suffix.
+ </p>
+ <p>
+ A particular response to the API — like a DNT response
+ header — is only valid immediately, and users may choose to
+ edit the list of stored exceptions and revoke some or all of them.
+ </p>
+ <p class="note">
+ The prior version of this call was asynchronous with a call-back; the change
+ to require the site to determine the user's wishes, rather than the UA,
+ enabled this to become synchronous. This is simpler; the user-agent may
+ still ask for the user's approval. Sites wishing to know whether an
+ exception stands, or the DNT header that they would receive,
+ should call the appropriate enquiry API.
</p>
</section>
<section id="exceptions-javascript-api-cancel">
<h3>API to Cancel a Site-specific Exception</h3>
- <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>boolean removeSiteSpecificTrackingException( )</dt>
+ <dl class="idl" title='partial interface Navigator'>
+ <dt>void removeSiteSpecificTrackingException( RemoveExceptionPropertyBag properties )</dt>
<dd>
- Ensures that the database of remembered grants no longer
- contains any duplets for which the first part is the current
- document origin; i.e., no duplets <code>[document-origin,
- target]</code> for any target. There is no callback. After the
- call has been made, it is assured that there are no
- site-specific or site-wide exceptions for the given
- top-level-domain.
+ <p>
+ If domain is not supplied or is null or empty then this
+ ensures that the database of remembered grants no longer
+ contains any duplets for which the first part is the current
+ document origin; i.e., no duplets <code>[document-origin,
+ target]</code> for any target.
+
+ </p>
+ <p>
+ If domain is supplied and is not empty then this
+ ensures that the database of remembered grants no longer
+ contains any duplets for which the first part is the
+ domain wildcard; i.e., no duplets <code>[*.domain, target]</code>
+ for any target.
+ </p>
+ <p>
+ There is no callback. After the
+ call has been made, it is assured that there are no
+ site-specific or site-wide exceptions for the given
+ top-level origin.
+ </p>
</dd>
</dl>
- <p>This returns a boolean indicating, when true, that the call has
- succeeded, and that the database of grants no longer contains,
- or very soon will no longer contain, the indicated grant(s); when false,
- some kind of processing error occurred.
+ <dl class="idl" title="dictionary RemoveExceptionPropertyBag">
+ <dt>DOMString? domain</dt>
+ <dd>Cookie-like domain string to which the exception applies.</dd>
+ </dl>
+ <p> When this method returns the database of grants no longer contains
+ the indicated grant(s); if some kind of processing error occurred then
+ an appropriate exception will be thrown.
+ </p>
+ <p class="note">
+ If there are no matching duplets in the database of remembered
+ grants when the method is called then this operation does nothing
+ (and does not throw an exception).
</p>
</section>
+
+ <section id="exceptions-javascript-api-confirm">
+ <h3>API to Confirm a Site-specific Exception</h3>
+
+ <dl class="idl" title='partial interface Navigator'>
+ <dt>boolean confirmSiteSpecificTrackingException (
+ ConfirmSiteSpecificExceptionPropertyBag properties)
+ </dt>
+ <dd>
+ Called by a page to confirm a site-specific tracking
+ exception.
+ </dd>
+ </dl>
+ <dl class="idl" title="dictionary ConfirmExceptionPropertyBag">
+ <dt>DOMString? domain</dt>
+ <dd>Cookie-like domain string to which the exception applies.</dd>
+ </dl>
+ <dl class="idl" title="dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBag">
+ <dt>sequence<DOMString> arrayOfDomainStrings</dt>
+ <dd>A JavaScript array of strings.</dd>
+ </dl>
+ <p>
+ If the call does not include the
+ <code>arrayOfDomainStrings</code>, then this call is to confirm a
+ site-wide exception. Otherwise each string in
+ <code>arrayOfDomainStrings</code> specifies a
+ <strong>target</strong>.
+ </p>
+ <p>
+ If the list <code>arrayOfDomainStrings</code> is supplied, and the
+ user-agent stores only site-wide exceptions, then the user-agent
+ MUST match by confirming a site-wide exception.
+ </p>
+ <p>
+ If the <code>domain</code> argument is not supplied or is null or empty
+ then the execution of this API uses the 'implicit' parameter,
+ when the API is called,
+ the <strong>document origin</strong>. This forms the first part of
+ the duplet in the logical model.
+ </p>
+ <p>
+ If the user-agent stores explicit lists, and the call includes one, the
+ database is checked for the existence of all the duplets (one per target):
+ </p>
+ <pre>[document-origin, target]</pre>
+
+ <p>
+ If the user-agent stores only site-wide exceptions or the call did
+ not include an explicit list, the database is checked for the
+ single duplet:
+ </p>
+ <pre>[document-origin, * ]</pre>
+ <p>
+ If the user-agent stores explicit lists, and the call includes one,
+ and the <code>domain</code> argument is provided and is not empty then the
+ database is checked for the existence of all the duplets (one per target):
+ </p>
+ <pre>[*.domain, target]</pre>
+
+ <p>
+ If the user-agent stores only site-wide exceptions or the call did
+ not include an explicit list, and the <code>domain</code> argument is
+ provided and is not empty then the database is checked for the single
+ duplet:
+ </p>
+ <pre>[*.domain, * ]</pre>
+
+ <p>
+ The returned boolean has the following possible values:
+ </p>
+ <ul>
+ <li><code>true</code> all the duplets exist in the database;</li>
+ <li><code>false</code> one or more of the duplets does not
+ exist in the database.</li>
+ </ul>
+ </section>
+
+
</section>
<section id="exceptions-ww-javascript-api">
@@ -1661,73 +1872,77 @@
<section id="exceptions-javascript-api-ww-rqst">
<h3>API to Request a Web-wide Exception</h3>
- <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>void requestWebWideTrackingException (
- in TrackingResponseCallback callback,
- optional siteName,
- optional explanationString,
- optional detailURI)
+ <dl class="idl" title='partial interface Navigator'>
+ <dt>void storeWebWideTrackingException (
+ StoreExceptionPropertyBag properties)
</dt>
<dd>
- If permission is granted, then the single duplet
- <code>[ * , document-origin]</code>
+ The single duplet
+ <code>[ * , document-origin]</code> or
+ <code>[ * , *.domain]</code> (based on if <code>domain</code>
+ is provided and is not null and not empty)
is added to the database of remembered grants.
- The parameters are as described
+ The members of the <code>StoreExceptionPropertyBag</code>
+ dictionary are as described
<a href="#exceptions-javascript-api">above</a> in the
request for site-specific exceptions.
</dd>
</dl>
<p>
- Users may wish to configure exceptions for a certain trusted
- tracker across all sites. This API requests the addition of a
+ This API requests the addition of a
web-wide grant for a specific site, to the database.
</p>
+ <p class="note">
+ As above, this call used to be asynchronous, and the change to the UI
+ enabled it to be synchronous.
+ </p>
</section>
<section id="exceptions-javascript-api-ww-cancel">
- <h3>API to cancel a web-wide exception</h3>
+ <h3>API to Cancel a Web-wide Exception</h3>
- <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>boolean removeWebWideTrackingException( )</dt>
+ <dl class="idl" title='partial interface Navigator'>
+ <dt>void removeWebWideTrackingException( RemoveExceptionPropertyBag properties )</dt>
<dd>
Ensures that the database of remembered grants no longer
- contains the duplet <code>[ * , document-origin]</code>.
+ contains the duplet <code>[ * , document-origin]</code>
+ or <code>[ * , *.domain]</code> (based on if <code>domain</code>
+ is provided and is not null and not empty).
There is no callback. After the call has been made, the
indicated pair is assured not to be in the database. The same
matching as is used for determining which header to send is used
to detect which entry (if any) to remove from the database.
</dd>
</dl>
- <p>This returns a boolean indicating, when true, that the call has
- succeeded, and that the database of grants no longer contains,
- or very soon will no longer contain, the indicated grant; when false,
- some kind of processing error occurred.
- </p>
</section>
- </section>
- <section id="exceptions-enquiry" >
- <h2>Querying a host's exception status</h2>
- <p class="issue" data-number="160" title="Do we need an exception-query API?"><b>[PENDING REVIEW]</b>
- 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. See proposal here.<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>
- <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
- <dt>DOMString requestDNTStatus( )</dt>
- <dd>
- Returns the same string value that would be sent in a
- <a>DNT-field-value</a> (<a href="#dnt-header-field"
- class="sectionRef"></a>) to a <strong>target</strong> that is the
- document-origin of the request, in the
- context of the current <strong>top-level domain</strong>. If no DNT
- header would be sent (e.g. because a tracking preference is
- <a>not enabled</a>) the return value is <code>null</code>.
- </dd>
+ <section id="exceptions-javascript-api-ww-confirm">
+ <h3>API to Confirm a Web-wide Exception</h3>
+
+ <dl class="idl" title='partial interface Navigator'>
+ <dt>boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag properties)
+ </dt>
</dl>
+ <p>
+ This API confirms the existence of a
+ web-wide grant for a specific site, in the database.
+ </p>
+ <p>
+ The returned boolean indicates whether the duplet
+ <code>[ * , document-origin]</code> or <code>[ * , *.domain]</code>
+ (based on if <code>domain</code> is provided and is not null and
+ not empty) exists in the database.
+ </p>
+ <ul>
+ <li><code>true</code> indicates that the web-wide exception exists;</li>
+ <li><code>false</code> indicates that the web-wide exception
+ does not exist.</li>
+ </ul>
+ </section>
</section>
-
+
<section id="transitive-exceptions">
<h2>Transfer of an exception to another third party</h2>
<p>A site may request an exception for one or more third party services used in
@@ -1794,57 +2009,40 @@
<h2>User interface guidelines</h2>
<p>
- User agents are free to implement exception management user
- interfaces as they see fit. Some agents might provide a prompt to
- the user at the time of the request. Some agents might allow users
- to configure this preference in advance. In either case, the user
- agent responds with the user's preference.
- </p>
- <p>
- In general, it is expected that the site will explain, in its online
- content, the need for an
- exception, and the consequences of granting or denying an exception, to
- the user, and guide. The call to the API and the resulting request for
- user confirmation should not be a 'surprise' to the user, or require
- much explanation on the part of the user-agent.
- </p>
- <p>
- A user agent that chooses to implement a prompt to present tracking
- exception requests to the user might provide an interface like the
- following:
+ As described above, it is the responsibility solely of the
+ site making the call to determine that an exception
+ grant reflects the user's informed consent at the time of the call.
</p>
- <pre class="example">
- Example News (<code>web.exnews.com</code>) would like to confirm
- that you permit tracking by a specific set of sites (click
- here for their names).
-
- Example News says:
- <q>These sites allow Example News to see how we're
- doing, and provide useful features of the Example News
- experience.</q> [More info]
-
- [Allow Tracking] [Deny Tracking Request]
- </pre>
<p>
- In this example, the domains listed are those specified in
- <code>arrayOfDomainStrings</code>, the phrase <q>Example News</q> is
- from <code>siteName</code>, and the <code>explanationString</code>
- is displayed for the user with a <q>More info</q> link pointing to
- <code>detailURI</code>.
+ It is expected that the site will explain, in its online
+ content, the need for an exception, and the consequences of granting or
+ denying an exception, to the user.
</p>
+
<p>
- The user agent might then store that decision, and answer future
- requests based on this stored preference. A user agent might provide
- the user with an interface to explicitly remove (or add)
- user-granted exceptions.
+ User agents are free to implement exception management user
+ interfaces as they see fit. Some agents might provide a notification to
+ the user at the time of the request, or even not complete the storing of
+ the exception until the user approves. Some agents might provide a
+ user-interface to see and edit the database of recorded exception grants.
+ The API parameters siteName, explanationString, and detailURI are
+ provided so that the user-agent may use them in their user interface.
</p>
<p>
- Users might not configure their agents to have simple values for
- DNT, but use different browsing modes or other contextual
- information to decide on a DNT value. What algorithm a user agent
- employs to determine DNT values (or the lack thereof) is out of the
- scope of this specification.
+ A user agent that chooses to highlight when tracking exceptions have been
+ stored might provide an interface like the following.
+ <ul>
+ <li>an icon in the status bar indicating that an exception has been
+ stored, which, when clicked on, gives the user more information about
+ the exception and an option to revoke such an exception.</li>
+ <li>an infobar stating "Example News (news.example.com) has indicated
+ to Browser that you have consented to granting it exceptions to your
+ general Do Not Track preference. If you believe this is incorrect,
+ click Revoke."</li>
+ <li>no UI at all.</li>
+ </ul>
</p>
+
<p>
In some user-agent implementations, decisions to grant exceptions
may have been made in the past (and since forgotten) or may have
@@ -1858,13 +2056,35 @@
trust without visiting that site.
</p>
- <p class="issue" data-number="140" title="Do we need site-specific exceptions, i.e., concrete list of permitted third parties for a site?">
- <b>[PENDING REVIEW]</b> In this section; yes, as some sites may
- have a mix of trusted/needed third parties, and others that either
- don't need to track, or aren't as trusted, or both. But all sites
- are (a) told what they got granted (list, or *) and (b) are assured
- that requests will be treated 'atomically'.
- </p>
+ </section>
+
+ <section id="exceptions-no-js" class="informative">
+ <h2>Exceptions without interactive JavaScript</h2>
+ <p>Some third party servers that comply with this standard may wish to
+ receive user-granted exceptions but when they are invoked as third
+ parties (using, for example, images, or "tracking pixels") do not
+ have an interactive JavaScript presence on the page. They cannot
+ request an exception under these circumstances, both because a
+ script is needed, and because they are required to explain to the
+ user the need for and consequences of granting an exception, and
+ get the user's consent. In general this process of informing,
+ getting consent, and calling the API is not expected to be in
+ the page where such trackers are invoked.</p>
+
+ <p>To obtain an exception, a document (page, frame, etc.) that
+ loads the Javascript is needed. The user may visit the site
+ that desires an exception directly, the first party site could
+ load a frame of the site desiring the exception, or that frame
+ might be part of some other page containing a number of frames,
+ which allows aggregation of requests for exceptions.</p>
+
+ <p>In all these ways, the site is contributing to informing the
+ user and getting their consent, and is also able to call the
+ Javascript API when it is granted.</p>
+
+ <p class="note">Depending on the resolution of options for the
+ User-Granted Exceptions section, this language might need to be
+ updated to correspond.</p>
</section>
<section id="exceptions-when-not-enabled">
@@ -1878,10 +2098,10 @@
</p>
<p>
User agents MAY instantiate
- <code>NavigatorDoNotTrack.requestSiteSpecificTrackingException</code>
+ <code>navigator.storeSiteSpecificTrackingException</code>
even when <code>navigator.doNotTrack</code> is null. Sites SHOULD
test for the existence of
- <code>requestSiteSpecificTrackingException</code> before calling
+ <code>storeSiteSpecificTrackingException</code> before calling
the method. If an exception is granted in this context and the
user-agent stores that preference, a user agent may send a DNT:0
header even if a tracking preference isn't expressed for other
@@ -1897,6 +2117,58 @@
the scope of this specification.
</p>
</section>
+
+ <section id="exceptions-by-sites">
+ <h3>Exception use by sites (informative)</h3>
+
+ <p>This section is to inform the authors of sites on some considerations
+ in using the exceptions APIs to best effect; sites of particular interest
+ here are those that need an exception in order to allow the user to perform
+ some operation or to have some access.
+ </p>
+
+ <p>The 'Store' calls do not have a return value, and return immediately.
+ If there is a problem with the calling parameters, then a Javascript
+ exception will be raised.
+ In addition, it may be that the user-agent does not immediately store
+ the exception, possibly because it is allowing the user to confirm.
+ Even though the site has acquired the user's informed consent before
+ calling the 'Store' API, it is possible that the user will change
+ their mind, and allow the store to proceed but then later ask it be
+ removed, or even by denying the storage in the first place.
+ </p>
+ <p class="note">The use of the word 'exception' both to describe
+ the user granting something, and for a problem in Javascript, is
+ an unfortunate clash here.
+ </p>
+
+ <p>Sites can call the 'Confirm' APIs to enquire whether a specific
+ exception has been granted and stands in the user-agent. This is the call
+ to make to determine whether the exception exists, and hence to control
+ access to the function or operation; if it fails (the exception has been
+ deleted, or not yet granted), then the user is ideally again offered
+ the information needed to give their informed consent, and again offered
+ the opportunity to indicate that they grant it. As stated in the normative
+ text, the site needs to explain and acquire consent immediately prior to
+ calling the Store API, and not remember some past consent; this allows the
+ user to change their mind.
+ </p>
+
+ <p>If they do grant it (using some positive interaction such as a button),
+ the site can return to checking the 'Confirm' API.
+ </p>
+
+ <p>In this way the site:
+ <ul>
+ <li>does not assume that the storage is instantaneous, and mistakenly
+ grant access when the exception does not (yet) stand;</li>
+ <li>does not call the Confirm API repeatedly without a user-interaction
+ between each call, in a loop;</li>
+ <li>permits the user the opportunity to delete a previously granted
+ exception.</li>
+ </ul>
+ </p>
+ </section>
<section id="exceptions-fingerprinting">
<h3 id="fingerprinting_concerns">Fingerprinting</h3>
Received on Wednesday, 17 April 2013 16:25:01 UTC