W3C home > Mailing lists > Public > public-tracking@w3.org > April 2013

DNT: Agenda for April 10 call

From: Peter Swire <peter@peterswire.net>
Date: Tue, 9 Apr 2013 13:59:17 -0700
To: "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <CD89F965.75B45%peter@peterswire.net>
(Very roughly, first half on compliance spec and second half on TPE spec.)


1. Confirmation of scribe – glad to accept volunteer  -- no volunteer thus far.

2. Offline-caller-identification:
If you intend to join the phone call, youmusteither associate your phone number with your IRC username once you've joined the call (command: "Zakim, [ID] is [name]" e.g., "Zakim, ??P19 is schunter" in my case), or let Nick know your phone number ahead of  time. If you are not comfortable with the Zakim IRC syntax for associating your phone number, please email your name and phone number to npdoty@w3.org<mailto:npdoty@w3.org>. We want to reduce (in fact, eliminate) the time spent on the call identifying phone numbers. Note that if your number is not identified and you do not respond to off-the-phone reminders via IRC, you will be dropped from the call.

Compliance Spec – Peter Swire

3.   User education/ User interface.

Proposed Text:
5. User Agent Compliance
A user agent MUST offer a control to express a tracking preference to third parties. The control MUST communicate the user's preference in accordance with the [TRACKING-DNT<http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-TRACKING-DNT>] recommendation and otherwise comply with that recommendation. A user agent MUST NOT express a tracking preference for a user unless the user has given express and informed consent to indicate a tracking preference.

While we do not specify how tracking preference choices are offered to the user or how the preference is enabled, each implementation MUST follow the following user interface guidelines:
1.     The User Agent is responsible for determining the user experience by which a tracking preference is enabled. For example, a user might select a check-box in their user agent's configuration, or install an extension or add-on that is specifically designed to add a tracking preference expression so long as the checkbox, extension or add-on otherwise follows these user interface guidelines;
2.     The User Agent MUST ensure that the tracking preference choices are communicated to users clearly and conspicuously, and shown at the time and place the tracking preference choice is made available to auser;
3.     The User Agent MUST ensure that the tracking preference choices accurately describe DNT, including the parties to whom DNT applies, and MUST make available via a link in explanatory text where DNT is enabled to provide more detailed information about DNT functionality.


The User Agent plays a key role in enacting the DNT functionality. As a result, it is appropriate for the User Agent to play an equally key role in describing DNT functionality and educating users about DNT in order for this standard to be meaningful.

While the user interface guidelines do not specify the exact presentation to the user, they are intended to help ensure that users understand their choices with respect to DNT. For example, outlining the parties (e.g., First Parties, Service Providers, Third Parties) to whomDNTapplies and using language that a reasonable user is likely to understand is critical for ensuring that users are in position to provide their informed consent to a tracking preference.

Moreover, as DNT functionality is complex, it is important that User Agents educate users about DNT, including but not limited to offering a clearly described link that takes the user to additional information about DNT functionality. For example, given that some parties may chose not to comply with DNT, it would be helpful for browsers to educate users about how to check the response header and/or tokens to see if a server is responding with a “public commitment” of compliance.

Finally, recognizing that DNT settings may be set by non-browser User Agents acting in violation of the user interface guidelines, the browsers should take reasonable steps to ensure that DNT settings are valid.

4. ACTION-373: Append.  Text proposed by John Simpson and Alan Chapell, with concurrence by Jeff Chester. Clarifications to list in emails by John Simpson April 8 and Peter Swire April 9.  Peter Swire circulated a background memo on April 9.

When DNT:1 is received:
-- A 1st Party MUST NOT combine or otherwise use identifiable data received from another party with data it has collected while a 1st Party.
-- A 1st Party MUST NOT shareidentifiable data with another party unless the data was provided voluntarily by the user and is necessary to complete a business transaction with the user.
-- A Party MUST NOT usedata gathered while a 1st Party when operating as a 3rd Party.
When DNT:1 is received, a 1st Party retains the ability to customize content, services, and advertising only within thecontext of the first party experience. A 1st party takes the user interaction outside of the 1st party experience if it receives identifiabledata from another party and uses that data for customization of content, services, oradvertising.
When DNT:1 is received the 1st Party maycontinue to utilize user provided data in order to complete or fulfill a user initiated business transaction such as fulfilling an order for goods or a subscription.
When DNT:1 is received and a Party has become a 3rd Party it is interacting with the user outside of the 1st Party experience.  Using data gathered while a 1st party is incompatible with interaction as a third party.

Chris Pedigo gave five examples on data append in September, 2012, which are useful to consider in light of the proposed language:

TPE Spec – Matthias Schunter
5. Restructuring the response indicators. We currently discuss thefollowing three fields:

- Optional Prefix "!" (I do not conform and I do not claim that whatever letters follow this sign are correct)
- Tracking Status
   1, 3, ...
- Permitted uses:
   C(onsent), ...

6.  ISSUE-187 Discuss Site Requirements Consent
One general concern related to exceptions in general was that sites register exceptions while neither the browser (in the old model) nor the site (in the new model) gather consent in a reliable way. Our current TPE spec states in Section 6.3.1:
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.

Jonathan proposed these three requirements that refine this language and that I would like to gather feedback on:
1) Actual presentation: The choice mechanism MUST be actually presented to the user.  It MUST NOT be on a linked page, such as a terms of service or privacy policy.

2) Independent choice: The choice mechanism MUST be presented independent of other choices.  It MUST NOT be bundled with other user preferences.

3) No default permission: The choice mechanism MUST NOT have the user permission preference selected by default.

(From http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0004.html )

7. Steps towards the next working draft.

Discuss what needs to be updated before publishing our next TPE working draft.

I have previously preferred distinguishing "who I am" from "how I am operating", and I feel that have C and ! as 'status' indicators rather than qualifiers means that I can no longer tell whether I am interacting with someone who adheres to 1st or 3rdparty constraints.  So I agree, rather than C or ! as the first character, I think that

1C -- content produced under first party rules with consent
3C -- third party under 3rd party rules with consent

8. Announce next meeting & adjourn

================ Infrastructure =================

Zakim teleconference bridge:
VoIP:    sip:zakim@voip.w3.org<file://localhost/sip/zakim@voip.w3.org>
Phone +1.617.761.6200 passcode TRACK (87225)
IRC Chat: irc.w3.org<http://irc.w3.org/>, port 6665, #dnt


Professor Peter P. Swire
C. William O'Neill Professor of Law
    Ohio State University
Received on Tuesday, 9 April 2013 20:59:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:09 UTC