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

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