- From: David Wainberg <dwainberg@appnexus.com>
- Date: Wed, 17 Apr 2013 12:01:22 -0400
- To: "Edward W. Felten" <felten@CS.Princeton.EDU>
- CC: "Alan Chapell (alternative)" <achapell@chapellassociates.com>, "<public-tracking@w3.org>" <public-tracking@w3.org>
- Message-ID: <516EC752.2050906@appnexus.com>
I think it should be fine to offer control over the DNT choice in a UI that is provided in a separate component, as long as it otherwise meets the guidelines. On 4/17/13 11:45 AM, Edward W. Felten wrote: > The main issue is that the proposed language would require the *user > agent* to present the user interface for consent. In any scenario > where a user agent is one component of a larger product or > configuration, it is possible to handle user communication through a > component other than the user agent itself. The main issue is whether > to prohibit this. > > > On Wed, Apr 17, 2013 at 11:35 AM, David Wainberg <david@appnexus.com > <mailto:david@appnexus.com>> wrote: > > I admit I'm confused about what the disagreement is. If the > ElectroCorp device is controlled via a web page, then that is the > UI to the device, and that is where the choice would be offered. > > > On 4/17/13 11:26 AM, Alan Chapell wrote: >> Thanks for the example, Ed. More below. >> From: "Edward W. Felten" <felten@CS.Princeton.EDU >> <mailto:felten@CS.Princeton.EDU>> >> Date: Wednesday, April 17, 2013 11:14 AM >> To: Alan Chapell <achapell@chapellassociates.com >> <mailto:achapell@chapellassociates.com>> >> Cc: "<public-tracking@w3.org <mailto:public-tracking@w3.org>>" >> <public-tracking@w3.org <mailto:public-tracking@w3.org>> >> Subject: Re: ACTION-390: alternative UA affordances for DNT choice >> >> Let me explain the music player scenario in more detail. >> >> >> I buy a small music player device from ElectroCorp. One of >> its capabilities is that it can download and play podcasts. >> Most podcasts are provided by third parties (radio stations, >> artists, record companies, tech companies, etc.) and are >> downloaded by the music player via HTTP. When the music >> player device connects to the Internet (via my home WiFi) and >> downloads podcasts, it is acting as a User Agent. >> >> ElectroCorp offers a website, "Manage Your Music Player", >> that I can use to control which podcasts I am subscribed to, >> among other things. But the music player itself doesn't >> offer any kind of general-purpose user interface. >> >> In this scenario, the user might want to limit the ability of >> third-party podcast providers to track me. To that end, the >> user might want to have the music player send DNT:1 when it >> is downloading podcasts. ElectroCorp might offer an >> interface on their web site that lets the user turn on DNT on >> his music player. The ElectroCorp site could be absolutely >> clear about what would be happening, what DNT does, and so >> on. It could meet any reasonable standard for clarity, >> communication, and consent. >> >> >> I don't see why having a website tied to the UA in the way you >> describe would violate the disclosure guidelines. If you feel it >> does, perhaps you and I can work on language to address this >> example. That said, most of the music services that I know of >> provide a robust UI (e.g., iTunes, Spotify) so this may be a >> fairly isolated example. And I don't believe that this scenario >> justifies throwing out the disclosure guidelines entirely — it >> seems that a better approach is to modify the guidelines to >> ensure that our mutual goal of ensuring informed consent is met. >> >> Does anyone have an issue with Ed's scenario? I'm not sure I >> fully understand Brooks' concern here – Brooks can you elaborate? >> >> >> I don't see why we would want to prohibit ElectroCorp from >> doing this. >> >> >> On Wed, Apr 17, 2013 at 10:53 AM, Alan Chapell >> <achapell@chapellassociates.com >> <mailto:achapell@chapellassociates.com>> wrote: >> >> Please see below. >> >> From: "Edward W. Felten" <felten@CS.Princeton.EDU >> <mailto:felten@CS.Princeton.EDU>> >> Date: Wednesday, April 17, 2013 10:39 AM >> To: Alan Chapell <achapell@chapellassociates.com >> <mailto:achapell@chapellassociates.com>> >> Cc: "<public-tracking@w3.org >> <mailto:public-tracking@w3.org>>" <public-tracking@w3.org >> <mailto:public-tracking@w3.org>> >> Subject: Re: ACTION-390: alternative UA affordances for >> DNT choice >> >> On Wed, Apr 17, 2013 at 10:01 AM, Alan Chapell >> <achapell@chapellassociates.com >> <mailto:achapell@chapellassociates.com>> wrote: >> >> [...] >> >> That said, I'm not sure we're asking the right >> question here. Its not "are there UA's that >> couldn't meet the guidelines?" -- The better >> question is: "are consumers better served by a >> standard that takes steps to ensure that Users >> are making an informed choice?" >> >> >> This is the key question, I think. Are we trying to >> enact particular guidelines? Or are we trying to >> make sure that users are making an informed choice? >> I think the latter is a better goal. >> >> >> The purpose of the proposed guidelines is to help ensure >> that the User is in position to make an informed choice. >> >> How does allowing UA's to enact DNT without offering >> information on what DNT does is help users to make >> informed choices? >> >> If we move forward with the proposed UA >> guidelines, that means certain UA's (e.g., dog >> collars, Ifttt, certain music players) won't be >> able to enact DNT in a compliant way – at least >> not initially. I don't see that as a bad thing >> given that consumers will certainly have other >> mechanisms where they can enact a valid DNT. Can >> you or someone else help me understand why this >> creates a poor outcome? >> >> >> Suppose the user doesn't want podcast providers to >> track their downloads. If we prohibit the music >> player from sending DNT: 1 --- even if the user has >> gotten full notification and made an informed choice >> --- then we are frustrating the user and forcing the >> music player maker to offer a less attractive product. >> >> >> Ed, are you suggesting that DNT is (or should be) the >> only way to stop the podcast provider from tracking >> downloads? I use Spotify, and that service offers ways to >> prevent others from seeing what I listen to on Spotify. >> DNT is one of many tools --- it is not supposed to be the >> ONLY tool. >> >> >> The difference here is between (a) requiring that the >> user's choice is informed and voluntary, versus (b) >> requiring that the user interface for that choice be >> provided directly by the UA software. I see the >> rationale for (a). I don't understand the rationale >> for (b). >> >> >> The rationale for B is this --- if you don't require >> those enacting DNT to disclose DNT functionality clearly >> and accurately, you frustrate the entire purpose of A. >> >> >> >> From: "Edward W. Felten" <felten@CS.Princeton.EDU >> <mailto:felten@CS.Princeton.EDU>> >> >> Date: Wednesday, April 17, 2013 8:51 AM >> To: "<public-tracking@w3.org >> <mailto:public-tracking@w3.org>>" >> <public-tracking@w3.org >> <mailto:public-tracking@w3.org>> >> Subject: ACTION-390: alternative UA affordances >> for DNT choice >> Resent-From: <public-tracking@w3.org >> <mailto:public-tracking@w3.org>> >> Resent-Date: Wed, 17 Apr 2013 12:52:30 +0000 >> >> Peter asked me to assemble some examples of >> User Agents offering different types of >> affordances for DNT choice. >> >> [First, for those with less experience in web >> standards, let's review the definition of >> "User Agent". The TPE spec includes a >> standard definition: "This specification uses >> the term user agent to refer to any of the >> various client programs capable of initiating >> HTTP requests, including, but not limited to, >> browsers, spiders (web-based robots), >> command-line tools, native applications, and >> mobile apps [HTTP11 >> <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#bib-HTTP11>]." >> HTTP requests are used for many purposes >> beyond loading HTML pages for display in >> browsers. Although we might be tempted to >> think of "User Agent" as synonymous with >> "browser," there are many UAs that are not >> browsers.] >> >> User Agent functionality is built into many >> types of consumer electronics or "smart >> object" products, including alarm clocks, >> pedometers, audio players, car electronics, >> bathroom scales, and even dog collars. (The >> collar reports your dog's location over >> time.) These are not hypotheticals; they are >> all real products on the market. Many >> products of this type do no offer a rich user >> interface on the device itself. Instead, >> they offer control and interaction via a web >> site provided separately from the product >> itself, which the consumer accesses using >> their ordinary desktop browser. >> >> For example, a music player device might >> offer the ability to subscribe to podcasts, >> with the device automatically downloading new >> podcast episodes from subscribed-to podcasts >> as they become available. When downloading a >> new podcast episode, the player device would >> be acting as a user agent (initiating an HTTP >> request). Yet the player device might not >> offer a user interface with rich controls. >> Instead, the user might set up and control >> their podcast subscriptions via an external >> website affiliated with the device. >> >> In this case, it is possible to offer the >> user DNT choice via the external website. >> But note that this choice would not be >> offered through the user agent (the music >> player device) itself---and the external >> website is not a user agent at all. >> Therefore a spec that required choice to be >> offered *directly by* the user agent would >> not be implementable in this scenario, while >> one that merely required clear choice *with >> respect to* the user agent would be >> implementable for this type of user agent. >> >> Another type of UA that can't offer a direct >> DNT affordance to the user is a service that >> acts asynchronously on the user's behalf. >> One example is Ifttt. You tell Ifttt a >> "recipe" such as "rebroadcast all of my >> Twitter tweets as Facebook wall posts" or >> "clip any Facebook photo tagged with my name >> and upload it into Evernote", etc. Then >> Ifttt periodically accesses the various sites >> on your behalf to carry out the recipes. >> When Ifttt accesses these sites, it is >> acting as a User Agent, but you are not >> present and this UA doesn't offer you a >> direct user interface. You can control the >> status of your Ifttt account via an external >> control panel, which is not a User Agent. >> Again, notification and choice are possible >> *for* the Ifttt User Agent, but not *through* >> the User Agent itself. >> >> This should give an idea of some of the >> scenarios that can come up. There are others >> that pose different challenges, such as >> command-line tools, or tools that user HTTP >> "in the background" to update code or data in >> an app, or code that isn't allowed to offer a >> rich user interface for security reasons. >> (A rich UI can be used, e.g., to trick the >> user into entering a sensitive password, so >> some systems block less-trusted code from >> displaying a rich or large UI.) >> >> >> >> >> -- >> Edward W. Felten >> Professor of Computer Science and Public Affairs >> Director, Center for Information Technology Policy >> Princeton University >> 609-258-5906 <tel:609-258-5906> >> http://www.cs.princeton.edu/~felten >> <http://www.cs.princeton.edu/%7Efelten> >> >> >> >> >> -- >> Edward W. Felten >> Professor of Computer Science and Public Affairs >> Director, Center for Information Technology Policy >> Princeton University >> 609-258-5906 <tel:609-258-5906> >> http://www.cs.princeton.edu/~felten >> <http://www.cs.princeton.edu/%7Efelten> >> > > > > > -- > Edward W. Felten > Professor of Computer Science and Public Affairs > Director, Center for Information Technology Policy > Princeton University > 609-258-5906 http://www.cs.princeton.edu/~felten > <http://www.cs.princeton.edu/%7Efelten>
Received on Wednesday, 17 April 2013 16:01:48 UTC