Re: ACTION-390: alternative UA affordances for DNT choice

This seems like a simple fix then.  Something along the lines of, "In the case were a UA does not have a sophisticated UI, that UA that expresses the DNT signal must be informed by the following requirements…"  I'm sure we can refine Alan's language to meet our goals.


Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group | Interactive Advertising Bureau - IAB

From: "Edward W. Felten" <felten@CS.Princeton.EDU<mailto:felten@CS.Princeton.EDU>>
Date: Wednesday, April 17, 2013 8:45 AM
To: David Wainberg - AppNexus <david@appnexus.com<mailto:david@appnexus.com>>
Cc: Alan Chapell - Chapell Associates <achapell@chapellassociates.com<mailto:achapell@chapellassociates.com>>, W3C DNT Working Group Mailing List <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: ACTION-390: alternative UA affordances for DNT choice
Resent-From: W3C DNT Working Group Mailing List <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Wednesday, April 17, 2013 8:45 AM

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