- From: David Singer <singer@apple.com>
- Date: Tue, 15 Jan 2013 16:35:15 -0800
- To: public-tracking-commit@w3.org
I've asked Nick to check 4.3
On the confirm calls, I expect even if we add either or both of the "and sub-domains" and/or "and my same-party sites", I would leave the confirm calls as-is, confirming whether "I" have the expected exception. Complicating them doesn't seem needed.
On Jan 15, 2013, at 16:28 , CVS User dsinger2 <cvsmail@w3.org> wrote:
> Update of /w3ccvs/WWW/2011/tracking-protection/drafts
> In directory gil:/tmp/cvs-serv643
>
> Modified Files:
> tracking-dnt.html
> Log Message:
> Edits for actions
> 345 - add section for sites that do not normally have a visual/JS presence (from
> Nick's text)
> 348 - ensure that the API allows the UA to pend the store while getting user
> approval
> 349 - add 'confirm' APIs for both site and web-wide exceptions
> 351 - remove the 'what is the user's general preference' check, and move the
> ';what header would I receive' call to that section in the document (still needs
> Nick to base this call on the right JS object)
> 353 - duplicate of 349
>
>
>
> --- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2012/12/07 00:26:44 1.174
> +++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2013/01/16 00:28:17 1.175
> @@ -421,55 +421,25 @@
>
> <section id='js-dom'>
> <h3>JavaScript API to Detect Preference</h3>
> - <p class="issue">This call is a candidate for deletion, relying only on the
> - origin-specific call below (Nick Doty's suggestion).
> - </p>
> -
> - <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
> + <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 origin</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>
> + <p>This call enables a site 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 exceptions.</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 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 request, 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 return value is <code>null</code>.
> + </dd>
> + </dl>
> </section>
>
> <section id='plug-ins'>
> @@ -1501,7 +1471,7 @@
> 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 stored, 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
> @@ -1552,7 +1522,7 @@
> <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>integer storeSiteSpecificTrackingException (
> @@ -1609,11 +1579,12 @@
> <ul>
> <li><code>0</code> indicates a syntax or other operational error.</li>
> <li><code>1</code> indicates that the request was for specific
> - <strong>target</strong>s and the the user-agent has stored an exception on
> + <strong>target</strong>s and the the user-agent has stored or will store
> + an exception on
> <strong>top-level origin</strong> for those specific
> <strong>target</strong>s.</li>
> - <li><code>2</code> indicates the user-agent has stored a site-wide exception
> - on <strong>top-level origin</strong> for all
> + <li><code>2</code> indicates the user-agent has stored or will store
> + a site-wide exception on <strong>top-level origin</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>
> @@ -1627,7 +1598,7 @@
> </p>
> <p>
> If permission is stored for a site-wide exception, then the
> - duplets:
> + duplet:
> </p>
> <pre>[document-origin, * ]</pre>
> <p>
> @@ -1641,8 +1612,10 @@
> <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, unless the UA
> - wishes to ask the user and not store until the user agrees.
> + 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>
>
> @@ -1667,6 +1640,70 @@
> some kind of processing error occurred.
> </p>
> </section>
> +
> + <section id="exceptions-javascript-api-confirm">
> + <h3>API to Confirm a Site-specific Exception</h3>
> +
> + <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
> + <dt>boolean confirmSiteSpecificTrackingException (
> + optional sequence<DOMString> arrayOfDomainStrings)
> + </dt>
> + <dd>
> + Called by a page to confirm a site-specific tracking
> + exception.
> + </dd>
> + </dl>
> +
> + <p>
> + The <code>confirmSiteSpecificTrackingException</code> method takes
> + one optional argument:
> + </p>
> + <ul>
> + <li><code>arrayOfDomainStrings</code>, a JavaScript array of
> + strings,</li>
> + </ul>
> + <p>
> + If the call does not include the
> + <code>arrayOfDomainStrings</code>, then this call is top 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>
> + 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>
> + 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">
> @@ -1699,16 +1736,16 @@
> </p>
> <ul>
> <li><code>0</code> indicates a syntax or other operational error.</li>
> - <li><code>1</code> indicates that the request was stored.</li>
> + <li><code>1</code> indicates that the request was or will be stored.</li>
> </ul>
> <p class="note">
> As above, this call used to be asynchronous, and the change to the UI
> - enabled it to be sycnhronous.
> + 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>
> @@ -1728,29 +1765,31 @@
> </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 origin</b> and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
> - </p>
> + <section id="exceptions-javascript-api-ww-confirm">
> + <h3>API to Confirm a Web-wide Exception</h3>
> +
> <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 origin</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>
> + <dt>boolean confirmWebWideTrackingException ()
> + </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> 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
> @@ -1830,10 +1869,11 @@
> <p>
> 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. Some agents might provide a
> + 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 this UI.
> + provided so that the user-agent may use them in their user interface.
> </p>
> <p>
> A user agent that chooses to highlight when tracking exceptions have been
> @@ -1872,6 +1912,35 @@
> </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">
> <h3>Exceptions without a DNT header</h3>
>
>
>
David Singer
Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 16 January 2013 00:35:46 UTC