- From: David Singer <singer@mac.com>
- Date: Thu, 06 Dec 2012 16:45:23 -0800
- To: "public-tracking@w3.org Working Group" <public-tracking@w3.org>
I have an action to suggest strengthening and shortening this text from Nick: On Oct 29, 2012, at 17:14 , Nicholas Doty <npdoty@w3.org> wrote: > I volunteered to write up a non-normative explanation of techniques a non-JS-based third party could use for obtaining a user-granted exception. Proposed text is below; this would be added to the end of the User-Granted Exceptions section in tracking-dnt.html. > > Thanks, > Nick > > # Exceptions without interactive JavaScript > (This section is non-normative.) > > Some third party servers that comply with this standard may wish to receive user-granted exceptions but not have an interactive JavaScript presence on the page. Such tracking elements (for example, images, or "tracking pixels") therefore cannot use the JavaScript APIs described in this section to request an exception from the user. Such servers may obtain user-granted exceptions to a Do Not Track preference in a few alternative ways: > > * If a user visits the home page of the third-party tracker in a first-party context, the tracker may in that context explain the exception request and use the JavaScript APIs to request a Web-wide exception. In the case of an exception granted in this way, the tracker will subsequently receive DNT:0 signals for requests to the corresponding domain. Alternately, a tracker could obtain out-of-band consent from the user (as defined in [TRACKING-COMPLIANCE]) and remember such consent via use of a cookie or similar technology. > * A third-party tracker may make arrangements with first-party publishers for the first-party to use the JavaScript APIs to request a site-wide exception. In the case of an exception granted in this way, the tracker will subsequently receive DNT:0 signals for requests within the context of that first-party. > * A third-party could provide transparency about their own data practices in order to persuade users to pre-emptively provide user-granted exceptions. A third-party tracker might use a machine-readable policy (for example, P3P) or some indication of compliance with a self-regulatory program or auditing practice . Users that care to might configure their user agents to grant exceptions (and thus send DNT:0 signals) to trackers with such practices. > > Notes: depending on the resolution of options for the User-Granted Exceptions section, this language might need to be updated to correspond. Suggested strengthening and shortening: # Exceptions without interactive JavaScript (This section is non-normative.) 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. 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. 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. Notes: depending on the resolution of options for the User-Granted Exceptions section, this language might need to be updated to correspond. Dave Singer singer@mac.com
Received on Friday, 7 December 2012 00:46:05 UTC