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

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