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

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