- From: Edward W. Felten <felten@CS.Princeton.EDU>
- Date: Wed, 17 Apr 2013 11:45:03 -0400
- To: David Wainberg <david@appnexus.com>
- Cc: Alan Chapell <achapell@chapellassociates.com>, "<public-tracking@w3.org>" <public-tracking@w3.org>
- Message-ID: <CANZBoGjmdg2sqdi1w0fmQ307C1znPWWGyhc1pdxdj9VUMy-xxQ@mail.gmail.com>
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> 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> > Date: Wednesday, April 17, 2013 11:14 AM > To: Alan Chapell <achapell@chapellassociates.com> > Cc: "<public-tracking@w3.org>" <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> wrote: > >> Please see below. >> >> From: "Edward W. Felten" <felten@CS.Princeton.EDU> >> Date: Wednesday, April 17, 2013 10:39 AM >> To: Alan Chapell <achapell@chapellassociates.com> >> Cc: "<public-tracking@w3.org>" <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> 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> >>> >>> Date: Wednesday, April 17, 2013 8:51 AM >>> To: "<public-tracking@w3.org>" <public-tracking@w3.org> >>> Subject: ACTION-390: alternative UA affordances for DNT choice >>> Resent-From: <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 http://www.cs.princeton.edu/~felten >> >> > > > -- > 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 > > > -- 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
Received on Wednesday, 17 April 2013 15:45:50 UTC