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

Thanks Ed. As I look through this list, you've clearly demonstrated that
there are user agents that would be unable to disclose DNT functionality as
specified through the proposed UA guidelines.

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?"

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?

Conversely, if we don't require the UA guidelines, we open the door to all
kinds of UA's enacting DNT in ways that are not understood by most
consumers. 

The marketplace will build around the standards that we establish here. Some
of the UA's you cite will figure out a way to meet the guidelines ­ and some
will not. And I think that's a much better outcome than creating a wild west
environment where most UA's can turn on DNT without adhering to generally
accepted privacy standards.


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-HTTP1
> 1> ]."    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.)
>