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

Hi Peter,

Please add my name to the list of those objecting the "wider scope" scenario you've described below, but I'd like to clarify my position: IF a web device offers its users a choice for DNT that is compliant with Alan's proposed text, then that device should fall in scope for sending DNT signals, otherwise it should not be considered a candidate to express a USER'S preference for DNT.

I've worked in technology for 20-years, and have been a consumer of technology for over 36-years.  My first "computer" was a Heath Kit digital signal processor that I assembled myself.  Today's average music player or Internet-connected scale has well over 1,000 times more processing power than my first computer; reference Moore's law (http://en.wikipedia.org/wiki/Moore's_law).  My point is, technology evolves, and rapidly, based on market requirements.  The very smart developers of the tech that Ed references below did not consider to employ sophisticated UIs because there was no market requirement requiring sophisticated UIs for these devices when they were designed/built.  When market requirements change, so do products.  My first digital music player (1996) did not have a screen at all— only buttons: skip forward, skip back, play, pause, on/off; but of course my iPod today has a very sophisticated touch screen that allows me to make hundreds, if not thousands of choices— because technology evolved to meet new market requirements.  My point is, IF the market demands a device's UI to allow users to make choices about DNT, then those products will evolve to include such a UI.

I've lead the development of several key industry technology specs.  Tech specs always make developers reach further, and this one should be no different.  By publishing our requirements, those who want to adhere to them will have to change their status quo.  For some that may involve relatively simply software updates, while others may have to modify hardware.  In any case, if the market thinks its worth doing, I am supremely confident, it will get done— we only have to look at our recent tech history to see proof.

Let's publish a spec that encourages privacy by design, with real live human users in control of their own choices.

Chris


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

From: Peter Swire - W3C TPWG Co-Chair <peter@peterswire.net<mailto:peter@peterswire.net>>
Date: Wednesday, April 17, 2013 7:54 AM
To: David Wainberg - AppNexus <david@appnexus.com<mailto:david@appnexus.com>>
Cc: "Edward W. Felten" <felten@CS.Princeton.EDU<mailto:felten@CS.Princeton.EDU>>, 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 7:54 AM

In my write up, I was not attempting to take a position about a correct answer for the standard.

I was attempting to highlight and clarify an issue.  Based on the threat so far, Ed's position appears different than that voiced by David Wainberg, Brooks Dobbs, and Alan Chapell.

In any discussion of user interface/user education, it seems that this issue would be a significant one to resolve.

Peter



Professor Peter P. Swire
C. William O'Neill Professor of Law
    Ohio State University
240.994.4142
www.peterswire.net

From: David Wainberg <david@appnexus.com<mailto:david@appnexus.com>>
Date: Wednesday, April 17, 2013 10:36 AM
To: Peter Swire <peter@peterswire.net<mailto:peter@peterswire.net>>
Cc: Ed Felten <felten@CS.Princeton.EDU<mailto:felten@CS.Princeton.EDU>>, "<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



First, let's be clear about DNT would apply. Let me know if I have this wrong. For a special purpose device, e.g. a net-enabled scale, data collection by the first party is implicit in the nature of the device, isn't it? And it's first party in any case. But, DNT would apply in two cases with these sorts of UA: 1) the UA is going to transfer 1st party data to a 3rd party, or 2) it is interacting with a 3rd party on the user's behalf.

Two comments regarding narrow vs broad scope. First, if there is no interface where the user can make a choice, how can the UA send DNT? Peter, are you saying that under a broader scope, these UAs could send DNT without offering the user a choice? Second, if UAs can send DNT without offering a choice, and then claim that's fine because they don't offer a UI, then we incentivize doing so. Not only is this a poor user experience, but it invites anti-competitive abuses of the DNT signal.

On 4/17/13 9:50 AM, Peter Swire wrote:
My thanks to Ed for writing this up so clearly.

As a follow-up, let's see if the following is accurate.  My point goes to advantages and disadvantages of having a broader vs. narrower set of user agents that are covered by the standard, with respect to user interface/user education.

Broader scope of UAs that comply with DNT.   This includes Ed's sort of examples.  There are smart objects such as bathroom scales or the podcast service.  Users may want to have DNT for these objects, so that their daily weight or music downloads are not tracked.  In Ed's examples, the DNT interface and choices would be expressed at a web site that is separate from the UA.  Presumably, full DNT functionality would exist on that web site, with respect to the UA.

Narrower scope of UAs that comply with DNT.  A narrower approach would say that the bathroom scales or podcast service do not qualify for DNT, because there is no user interface directly by the UA.  The idea here might be that it is necessary for DNT to apply for the UA itself to have the user interface built in.

I believe that Ed is supporting the broader scope, so that user choice is achieved for this broader range of UAs.

Are there objections/concerns to this approach, so that some in the group would only support the narrower scope?  What would the basis be for such concerns?

Thank you,

Peter



Professor Peter P. Swire
C. William O'Neill Professor of Law
    Ohio State University
240.994.4142
www.peterswire.net<http://www.peterswire.net>

From: Ed 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: Wednesday, April 17, 2013 8:52 AM

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.)