- From: Alan Chapell <achapell@chapellassociates.com>
- Date: Tue, 09 Apr 2013 18:26:12 -0400
- To: Justin Brookman <justin@cdt.org>, <public-tracking@w3.org>
- Message-ID: <CD8A0D68.2E9B6%achapell@chapellassociates.com>
I'll be presenting the language with input from others. Once we reach consensus on this language I'd be happy to work with you on language for exception requests. From: Justin Brookman <justin@cdt.org> Date: Tuesday, April 9, 2013 5:26 PM To: <public-tracking@w3.org> Subject: Re: DNT: Agenda for April 10 call Resent-From: <public-tracking@w3.org> Resent-Date: Tue, 09 Apr 2013 21:26:58 +0000 > > > Who is presenting the language on user interface? The group had previously > agreed that the degree of specificity on user agent presentation of DNT > options should also be mirrored in presentation requirements for exception > requests. So if we're requiring "clear and conspicuous" presentation and an > explanatory link for turning DNT on in the first place, we're also going to > have to require the same for parties seeking to get permission to ignore a > DNT:1 signal. > > Justin Brookman > Director, Consumer Privacy > Center for Democracy & Technology > tel 202.407.8812 > justin@cdt.orghttp://www.cdt.org > @JustinBrookman > @CenDemTech > On 4/9/2013 4:59 PM, Peter Swire wrote: > > >> >> >> >> >> >> (Very roughly, first half on compliance spec and second half on TPE spec.) >> >> >> >> >> --------------------------- >> >> Administrative >> >> --------------------------- >> >> >> >> 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. 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#b >> ib-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. >> >> >> >> Non-Normative: >> >> >> >> 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. >> >> >> >> Normative: >> >> 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. >> >> Non-Normative: >> >> 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: >> >> http://www.w3.org/2011/tracking-protection/track/actions/229 >> >> >> >> --------------------------- >> >> 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 >> <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 >> >> 240.994.4142 >> >> www.peterswire.net <http://www.peterswire.net> >> >> >> >> >> > >
Received on Tuesday, 9 April 2013 22:26:44 UTC