- From: CVS User rfieldin <cvsmail@w3.org>
- Date: Mon, 23 Mar 2015 20:58:25 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv2990
Modified Files:
tracking-dnt.html
Log Message:
(editorial) Fix many occurrences of normative indicator words being used for non-normative discussion, a few grammar issues, and some comma abuse
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2015/03/23 18:40:24 1.282
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2015/03/23 20:58:25 1.283
@@ -82,7 +82,7 @@
issues regarding this document.
</p>
<p>
- The following features are at risk and may be cut from the specification
+ The following feature is at risk and might be cut from the specification
during its CR period if there are no (correct) implementations:
</p>
<ul>
@@ -1472,12 +1472,12 @@
<p>
User-granted exceptions to Do Not Track, including site-specific
exceptions, are agreed between the site and the user, and stored by
- the user agent. A resource ought to rely on the DNT header it
+ the user agent. A resource ought to rely on the DNT header field 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.
+ can request and check the status of exceptions for tracking.
</p>
- <p class="note">We envisage that the exceptions may also be usable as
+ <p class="note">We envisage that the exceptions might also be usable as
a consent mechanism.
</p>
</section>
@@ -1490,67 +1490,67 @@
exceptions.
</p>
<ul>
- <li>Content providers may wish to prompt visitors to their
+ <li>Content providers might wish to prompt visitors to their
properties to <q>opt back in</q> to tracking for behavioral
advertising or similar purposes when they arrive with the Do Not
Track setting enabled.</li>
- <li>Privacy-conscious users may wish to view or edit all the
+ <li>Privacy-conscious users might wish to view or edit all the
exceptions they've granted in a single, consistent user interface,
rather than managing preferences in a different way on every
content provider or tracker's privacy page.</li>
- <li>Granting an exception in one context (while browsing a news
- site) should not apply that exception to other contexts (browsing
- a medical site) that may not be expected.</li>
- <li>Tracking providers should not ever have to second-guess a
- user's expressed Do Not Track preference.</li>
- <li>The solution should not require cross-domain communication
+ <li>Granting an exception in one context (e.g., while browsing a news
+ site) does not imply that exception is applicable to other contexts
+ (e.g., browsing an unrelated medical site).</li>
+ <li>Tracking providers ought to be able to avoid second-guessing a
+ user's expressed tracking preference.</li>
+ <li>The solution need not require cross-domain communication
between a first-party publisher and its third parties.</li>
</ul>
<p>
When asking for a site-specific exception, the top-level origin
- making the request may be making some implicit or explicit claims as
+ making the request might make 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
sure that those claims are true. (Consider a site that has some
- trusted advertisers and analytics providers, and some mashed-up
+ trusted advertisers and analytics providers, along with some mashed-up
content from less-trusted sites). For this reason, there is support
both for explicitly named sites, as well as support for granting an
exception to all third-parties on a given site (site-wide exception,
using the conceptual wild-card "*").
</p>
<p>
- There are some cases in which a user may desire a site to be allowed
+ There are some cases in which a user might desire a site to be allowed
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.
+ a site might obtain such a web-wide exception from the user.
</p>
</section>
<section id='exception-model'>
- <h3>Exception model</h3>
+ <h3>Exception Model</h3>
<section>
<h4>User Interaction</h4>
<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
+ to grant an exception at the time of that 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
+ exception, at the time of the call. (This allows a user to
+ change their mind and delete a stored exception, which might result
+ in the site explaining and asking for the exception again.)
+ It is the sole responsibility 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>
- 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>
+ informed consent at the time of that call.
+ </p>
+ <p>
+ A site 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>
<li>To allow the user to confirm a user-granted exception prior
@@ -1562,18 +1562,18 @@
<li>To allow the user to see and possibly revoke stored
exceptions;
<li>Other aspects of the exception mechanism, as desired.</li>
- </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>
- If the user revokes the consent by deleting the exception, the
- site MUST respect that revocation (though it may ask again for
- the exception). The exception mechanism MUST NOT be used when the
- site will deem consent to exist even after the exception has been
- revoked.
- </p>
+ </ul>
+ There is no required user interface for the user agent;
+ a user agent MAY choose to provide no user interface regarding
+ user-granted exceptions.
+ </p>
+ <p>
+ If the user revokes the consent by deleting the exception, the
+ site MUST respect that revocation (though it MAY ask again for
+ the exception). The site MUST NOT use this exception mechanism if it
+ will deem consent to exist even after the exception has been
+ revoked.
+ </p>
</section>
<section>
@@ -1592,13 +1592,14 @@
specification, we define three terms:
</p>
<ul>
- <li><strong>top-level origin</strong> is a <strong>top-level
- browsing context</strong> as defined in [[!HTML5]]</li>
- <li>A <strong>target</strong> site is the Host part of an HTTP URL
- as defined in [[!RFC3986]]</li>
+ <li>A <strong>top-level origin</strong> is the <strong>top-level
+ browsing context</strong>, as defined by [[!HTML5]];</li>
+ <li>A <strong>target</strong> site is the host subcomponent of the
+ authority part in an "http" or "https" URI, as defined by
+ [[!RFC7230]] and [[!RFC3986]]; and,</li>
<li>The <strong>document origin</strong> of a script is the
- <strong>effective script origin</strong> as defined in
- [[!HTML5]]</li>
+ <strong>effective script origin</strong>, as defined by
+ [[!HTML5]].</li>
</ul>
<p>
For instance, if the document at
@@ -1620,8 +1621,8 @@
<li>Domain names passed to the API.</li>
</ul>
<p>
- Domains that enter into the decision over what DNT header to be
- sent in a given request include:
+ Domains that enter into the decision over what DNT header field to
+ be sent in a given request include:
</p>
<ul>
<li>The <strong>top-level origin</strong> of the current browser
@@ -1629,23 +1630,23 @@
<li>The <strong>target</strong> of the request.</li>
</ul>
<p class="note">
- Note that these strict, machine-discoverable concepts may not
+ Note that these strict, machine-discoverable concepts might not
match the definitions of first and third party; in particular,
- sites themselves need to determine (and signal) when they get
- 'promoted' to first party by virtue of user interaction; the UA
- will not change the DNT header it sends them.
+ sites themselves need to determine when they are a first party in
+ relation to a given user action; the user agent does not change the
+ DNT header field based on the type of network interaction.
</p>
<p>
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>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>The user agent adds to its local database one or more site-pair
+ duplets [document-origin, target]; one or the other of these MAY
+ be a wild-card ("*");</li>
<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 origin, target domain] matches any duplet in the
+ and a DNT header field is to be sent to a target domain, if the
+ duplet [top-level origin, target domain] matches any duplet in the
database, then a <code><a>DNT:0</a></code> preference is sent,
otherwise the user’s general preference is sent (if any).</li>
</ul>
@@ -1684,20 +1685,19 @@
their names might mean little to the user. The user might, for
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.
+ listing them by name; or the user agent might decide to store a
+ site-wide exception, effectively ignoring any list of domain names.
</p>
<p>
- 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.
+ Conversely, if a wild-card is used, the user might be told that
+ there is a stored exception for all third-parties that are embedded
+ by the indicated top-level origin.
</p>
</section>
</section>
<section id="exceptions-javascript-api">
- <h3>JavaScript API for Site-specific Exceptions</h3>
+ <h3>Site-specific Exceptions</h3>
<section id="exceptions-javascript-api-rqst">
<h4>API to Request a Site-specific Exception</h4>
@@ -1783,7 +1783,7 @@
host name, up to one level below TLD.
</p>
<p>
- For example, <em>www.foo.bar.example.com</em> may set the domain
+ For example, <em>www.foo.bar.example.com</em> can 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>.
@@ -1812,9 +1812,9 @@
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 may choose to
- edit the list of stored exceptions and revoke some or all of them.
+ A particular response to the API — like a DNT response header
+ field — is only valid immediately; a user might later choose
+ to edit stored exceptions and revoke some or all of them.
</p>
<p>
If <code>expires</code> is supplied and not null or empty the
@@ -1957,7 +1957,7 @@
</section>
<section id="exceptions-ww-javascript-api">
- <h3>JavaScript API for Web-wide Exceptions</h3>
+ <h3>Web-wide Exceptions</h3>
<section id="exceptions-javascript-api-ww-rqst">
<h4>API to Request a Web-wide Exception</h4>
@@ -1994,8 +1994,9 @@
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.
+ matching process defined for determining which header field to
+ send is also used to detect which entry (if any) to remove from
+ the database.
</dd>
</dl>
</section>
@@ -2029,14 +2030,14 @@
<h3>User Interface Guidelines</h3>
<p>
- As described above, it is the responsibility solely of the site
- making the call to determine that an exception grant reflects the
+ As described above, it is the sole responsibility of the site
+ making an API call to determine that an exception grant reflects the
user's informed consent at the time of the call.
</p>
<p>
- 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.
+ It is expected that a site will explain to the user, in its online
+ content, the need for an exception and the consequences of granting or
+ denying that exception.
</p>
<p>
User agents are free to implement exception management user
@@ -2045,14 +2046,14 @@
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. If user-agents present this to the user, it
- should be clear that they are claims by the site, and might be
- written to mislead.
+ and detailURI are provided so that the user agent can use them in
+ their user interface. If a user agent presents these parameters to the
+ user, it ought to be clear that they are provided for informational
+ value and are less important than the exception's technical effect.
</p>
<p>
A user agent that chooses to highlight when tracking exceptions have
- been stored might provide an interface like the following.
+ been stored might provide an interface like the following:
</p>
<ul>
<li>an icon in the status bar indicating that an exception has been
@@ -2066,15 +2067,14 @@
</ul>
<p>
In some user agent implementations, decisions to grant exceptions
- may have been made in the past (and since forgotten) or may have
- been made by other users of the device. Thus, exceptions may not
+ might have been made in the past (and since forgotten) or might have
+ been made by other users of the device. Thus, exceptions might not
always represent the current preferences of the user. Some user
agents might choose to provide ambient notice that user-opted
tracking is ongoing, or easy access to view and control these
- preferences. Users may desire options to edit exceptions either at
- the time of tracking or in a separate user interface. This might
- allow the user to edit their preferences for a site they do not
- trust without visiting that site.
+ preferences. Users might also desire to edit exceptions within a
+ separate user interface, which would allow a user to modify their
+ stored exceptions without visiting the target sites.
</p>
</section>
@@ -2082,39 +2082,39 @@
<h3>Exceptions without Interactive JavaScript</h3>
<p>
- Some third party servers 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
+ Some third party servers that might wish to receive a user-granted
+ exception do not have the ability to invoke an interactive JavaScript
+ presence on a page (for example, those that provide only images or
+ "tracking pixels"). They cannot request an exception under these
+ circumstances, both because a script is needed, and because they would
+ be 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.
+ expected within page elements 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
+ the Javascript is needed. The user might 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.
+ In all these ways, the site is contributing to informing the user and
+ obtaining their consent, while enabling a call to the Javascript API
+ when such consent is granted.
</p>
</section>
<section id="exceptions-when-not-enabled">
- <h3>Exceptions without a DNT header</h3>
+ <h3>Exceptions without an Expressed Preference</h3>
<p>
Sites might wish to request exceptions even when a user arrives
- without a DNT header. Users might wish to grant affirmative
[65 lines skipped]
Received on Monday, 23 March 2015 20:58:30 UTC