- From: David Wainberg <david@appnexus.com>
- Date: Wed, 17 Apr 2013 11:35:34 -0400
- To: Alan Chapell <achapell@chapellassociates.com>
- CC: "Edward W. Felten" <felten@CS.Princeton.EDU>, "<public-tracking@w3.org>" <public-tracking@w3.org>
- Message-ID: <516EC146.5080902@appnexus.com>
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 http://www.cs.princeton.edu/~felten > <http://www.cs.princeton.edu/%7Efelten> >
Received on Wednesday, 17 April 2013 15:36:00 UTC