Re: Modifying a DNT Header (ISSUE-153, ACTION-285)

I'm not sure how you propose doing this. Trying to figure out what a piece
of software will or will not do under a given circumstance is directly
reducible to the halting problem (
http://en.wikipedia.org/wiki/Halting_problem) which is undecidable in the
general case. That is, there is no algorithm that the browser could run to
figure out what an arbitrary extension will do, much less whether whatever
UI the extension presented accurately elicited the user's intent. The fact
that it runs inside the browser does not make this a solveable problem.

-Ian

On Thu, Nov 8, 2012 at 12:16 PM, David Wainberg <
david@networkadvertising.org> wrote:

>  Hi James,
>
> I disagree with your take on this.
>
>
> On 11/8/12 1:42 PM, Grimmelmann, James wrote:
>
> A browser is not in a position to determine whether an extension has obtained user consent, just like a server is not in a position to determine whether a browser has obtained user consent.  The extension is effect a program of its own; it communicates with the browser through APIs. The browser can't peek over the extension's shoulder in a way that will enable it to fully understand what the user is seeing and doing.
>
>  The extension is not a program of its own. It is, by definition, an
> extension of the enclosing software, relying on the functionality provided
> by that software, and subject to the limitations imposed by that software.
> The browser can indeed peek over the extension's shoulder and ensure that
> the user's preference is accurately reflected in the signal that *the
> browser* sends.
>
>  The only way for a browser to be certain that any DNT-affecting extension meets its own standards for user consent would be to take complete control of the UI for setting or unsetting DNT.  But the consensus on this list has been strongly against trying to specify UI.
>
>  Although the charter does not allow for the specification of UI,
> guidelines for UI are explicitly in scope, as are other non-ui requirements
> placed on user agents.
>
> -David
>
>  James
>
> --------------------------------------------------
> James Grimmelmann              Professor of Law
> New York Law School                 (212) 431-2864
> 185 West Broadway       james.grimmelmann@nyls.edu
> New York, NY 10013    http://james.grimmelmann.net
>
> On 2012-11-08, at 1:13 PM, Shane Wiley <wileys@yahoo-inc.com> <wileys@yahoo-inc.com> wrote:
>
>
>  David,
>
> This would be a bad actor scenario.  If this occurs too often, I fear not many Servers will implement DNT as it is too easily gamed.  It would be best to have web browsers develop some degree of verification/logging here.
>
> Much like we've discussed in UGEs, there is a logged record of the exception so this will balance out bad actors (as they wouldn't typically want to say they support DNT and develop bad evidence like this).
>
> In the 3rd party plug-in/download application scenario we don't have a similar outcome that helps contain bad actors.
>
> - Shane
>
> -----Original Message-----
> From: David Wainberg [mailto:david@networkadvertising.org <david@networkadvertising.org>]
> Sent: Thursday, November 08, 2012 10:50 AM
> To: Shane Wiley
> Cc: Joseph Lorenzo Hall; Walter van Holst; public-tracking@w3.org
> Subject: Re: Modifying a DNT Header (ISSUE-153, ACTION-285)
>
> What would happen in the case of a browser plugin that turns DNT w/out the user's consent, and does not add the flag? Will the browser send
> DNT:1 w/out the flag? Or will it stop and figure out where it came from?
>
> On 11/8/12 10:38 AM, Shane Wiley wrote:
>
>  Yes.
>
> -----Original Message-----
> From: Joseph Lorenzo Hall [mailto:joe@cdt.org <joe@cdt.org>]
> Sent: Thursday, November 08, 2012 7:45 AM
> To: Shane Wiley
> Cc: Walter van Holst; public-tracking@w3.org
> Subject: Re: Modifying a DNT Header (ISSUE-153, ACTION-285)
>
> Shane is this as easy as inserting a field that says what UA set DNT?
>
> best, Joe
>
> --
> Joseph Lorenzo Hall
> Senior Staff Technologist
> Center for Democracy & Technologyhttps://www.cdt.org/
>
> On Nov 7, 2012, at 16:06, Shane Wiley <wileys@yahoo-inc.com> <wileys@yahoo-inc.com> wrote:
>
>
>  Walter,
>
> I disagree on all of your examples - and the current draft already speaks to intermediaries such as corporate or library scenarios.  If Severs have no confidence that USERS are directly activating DNT, they will not implement DNT (for the most part, I'm sure a few Universities would still implement since they don't rely on online advertising to pay for their web sites).
>
> I'm not asking for the UA to police the situation (although that would be best) but rather to provide a method for good actor 3rd party tools to declare they are the ones setting/sending the DNT signal, not the web browser.
>
> - Shane
>
> -----Original Message-----
> From: Walter van Holst [mailto:walter.van.holst@xs4all.nl <walter.van.holst@xs4all.nl>]
> Sent: Wednesday, November 07, 2012 1:52 PM
> To: public-tracking@w3.org
> Subject: Re: Modifying a DNT Header (ISSUE-153, ACTION-285)
>
> On 11/7/12 9:18 PM, Shane Wiley wrote:
>
>  As long as 3rd party changes are recorded and sent to the Server for
> assessment (Issue-143).  If 3rd party tools can game DNT (activate
> it with no user interaction and make it appear as if the browser is
> doing this), then I doubt many Servers will ever implement DNT.
> This is a critical issue that needs to be resolved to the
> satisfaction of both sides of the debate if there is any hope for
> DNT to be a viable, voluntarily implemented, standard.
>
>  That requirement that is impossible to meet. The UA has no control over the network between the UA and the server and therefore possibly cannot even detect such changes, let alone send them to the server for assessment.
>
> A few scenarios:
>
> 1) User A uses a Chromebook in an enterprise environment, managed by X.
> X has per corporate security policy transparant proxies for all HTTP traffic that insert DNT:1 for all outgoing HTTP requests, regardless of User A's preferences.
>
> 2) User B uses Chrome on a desktop machine that has an ad-blocking proxy installed, the Chrome configuration points to 127.0.0.1:8080 as a proxy, but other than that the UA has no real means to detect that there is a proxy and what it does. This particular proxy puts in DNT:1, without even paying attention to the Chrome preferences in this regard.
>
> 3) User C uses Chrome in conjunction with an extension that is acquired from outside Google's extension appstore. The extension leaves the Chrome DNT preferences untouched, but nonetheless puts in DNT:1 in outgoing HTTP requests.
>
> How is Chrome going to be compliant with your requirement in any of the above scenarios, neither of which is unlikely to ever happen?
>
> And I don't even think it should be problematic in the above given scenarios. In scenario 1, User A has to adhere to a corporate policy and given the business nature of the relationship with X (for example employer-employee relation), it can be argued that A's preferences are not relevant and only X's preferences.
>
> In scenarios 2 and 3 the user most likely chose consciously to use these third party tools and it can be equally argued that the browser configuration just not happens to reflect the users informed non-consent with being tracked and that the third-party tool installation does a better job at that.
>
> Bottom line: let's honour the principle that the user gets to decide what happens on his or her machine and not include second guesses of the user's stated intent in the specification.
>
> Regards,
>
> Walter
>
>
>
>
>
>