Re: ISSUE-95: May an institution or network provider set a tracking preference for a user?

On 2011-12-19, at 19:00 +0100, Shane Wiley wrote:

> Roy,
> 
> I would suggest we only add this comment to the Compliance document as many who are reading that document will not be very familiar with the broader array of W3C standards such as HTTP.  Are you comfortable with that path?
> 

I think you're onto something here, even though I disagree with the specific proposal you're making.

The discussion of this issue mixes two discussions on very different levels of abstraction.


1. An HTTP header definition actually needs to say what the expected behavior of HTTP intermediaries is for the header, and a few other things along the way.

I believe that we all agree that DNT is an end-to-end header, and that (from a protocol perspective) HTTP intermediaries MUST NOT mess with it.  That's the material that's currently in the header specification and that Roy is staunchly defending against being watered down.

This part of the discussion is about a technical protocol definition, and it's generally a good idea to avoid ambiguity and phrase that sort of thing in clear terms (MUST and MUST NOT) when possible.

A protocol definition like this one sits, by its very nature, on top of any number of layers of abstraction.  And that's just fine, because it permits us to keep the document short and clear.  One of the abstractions in the current text is to just summarily model the complex system of the enterprise administrator, the librarian, and and number of other players into "the user".


2. There is a much broader conversation going on about a number of other concerns: What if the user is in an enterprise that centrally manages certain browser settings?  What if there's a preconfigured user agent?  What if we're getting into the muddy waters where some sort of intermediary-like thing is used to extend the user agent (think privoxy for an example) and enforce certain policies that really belong into the user agent?

From the perspective of just writing a technical header specification, these concerns are best left out of scope.  They're not unique to any specific header, which suggests against trying to cover all of them in each header definition one tries to write — imagine every single feature that's added to HTTP started to go into a definition of public libraries.


What is unique to DNT, though, is that we're also talking to an audience that is likely to read both specifications from a policy perspective, and doesn't come pre-equipped with the usual abstractions that are applied as one works on HTTP.

Therefore, I think it's worth our while to explain that the abstraction occurs, and that we're not ignoring the messiness of the real world by using it.  Section 3 of the specification does some of that.


How about we add some *non-normative* text to section 3 of the header definition that explains things a bit more, but doesn't actually change the nature of the protocol definition?  Borrowing heavily from Tom's earlier text, I could imagine adding something like this to section 3:


>>>

Note: There are some situations where an entity other than the user wishes to express a Do Not Track preference on the user's behalf. Such situations may include those where the user has designated another person as their system's administrator, such as in a shared computing environment like an employer's network, or a public-use computer system like a library.   

In some of these situations, intermediaries are used to make certain choices on the user's behalf. If an intermediary modifies or sends a Do Not Track signal on the user's behalf, and that modification or sending does not occur within the user-agent, the scope of such modification should be as limited as possible. Extreme care should be taken to ensure that any modification accurately and completely expresses the user's preference. In particular, the intermediary should take care to avoid disrupting user's site-specific preferences and exceptions, and not to cause undue impact to the user's browsing experience.

<<<


> - Shane  
> 
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com] 
> Sent: Monday, December 19, 2011 5:16 AM
> To: <public-tracking@w3.org> (public-tracking@w3.org)
> Subject: Re: ISSUE-95: May an institution or network provider set a tracking preference for a user?
> 
> I've looked at ISSUE-95 in detail now, including the texts proposed by
> Shane and Tom (quoted below), and I believe it is inappropriate to make
> these changes to the TPE spec.  I have added issue markers to the spec
> to highlight the two places where text currently exists.  Naturally,
> the WG can choose to override my opinion.
> 
> First, the Description in the issue 
> 
>  http://www.w3.org/2011/tracking-protection/track/issues/95
> 
>  The point Rigo made was that we can specify user agent and server
>  behavior. However, we have no control over the transmission in between.
>  Therefore, requiring that the DNT flag MUST not be modified in transit
>  (unless explicitly authoirzed by the user) is futile.
> 
> is not even remotely true.   HTTP has literally hundreds of requirements
> that apply to intermediaries and message forwarding, and many more
> requirements that govern the semantics of a header field when transmitted
> via HTTP.  The DNT header field has such specific semantics -- it represents
> the user's expression of a tracking preference.
> 
> If an ISP adds DNT to messages without being instructed to do so by the
> user, then it violates the semantics of DNT and thereby fails to comply
> with HTTP.  When intermediaries violate HTTP (and more than a few do, but
> usually for the sake of caching or user authentication), recipients may
> adjust their behavior accordingly to fix the communication (if possible).
> Nevertheless, it is called a protocol error and we deploy workarounds to
> fix them -- there is no need to pepper the spec with SHOULDs when we know
> that the result fails to adhere to the header field definition.
> 
> Second, the administrative issues that Andy referred to, namely how an
> enterprise supplies only limited or preconfigured versions of software
> to its machines, is a different concern and should be considered as a
> separate issue (if necessary).  It is equivalent to the case where a
> user has decided to use a privacy-enhancing browser by name rather
> than a general-purpose one; the only difference here is that they were
> not given a choice of what clients could be installed.
> 
> This is an important distinction.  If I walk into a library and use one
> of their kiosks, I expect to be limited in choice and configuration by
> whatever browser they have chosen to install. [Actually, I would expect
> them to be configured in private browsing mode and a periodic logout,
> and thus not need to set DNT, but that's another story.]
> 
> In contrast, if I walk into a library and use their wireless Internet
> access on my own laptop, it would be a protocol violation for the library
> to modify the messages that are sent by my laptop in order to add DNT.
> The effect of that protocol violation will be seen in unexpected loss of
> functionality at the services I choose to access and some very confusing
> dialogs from service providers that ask me to "turn off DNT" when I
> haven't configured it in the first place.
> 
> Finally, I refuse to describe the protocol differently than how it is
> required to operate.  Changing the current MUST requirements in the
> spec mean that I have to go back and rewrite all the sections that talk
> about how DNT is a user preference, and hence the suggested changes
> would be insufficient to accomplish the changed semantics.  While I
> don't expect change proposals to spell out all the details, please
> understand that this proposal would lead to messy changes throughout
> the spec and significantly dilute the main reason for service providers
> to implement the protocol as specified: to meet the user's expectations.
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>
> 
> 
> On Nov 30, 2011, at 10:21 AM, Tom Lowenthal wrote:
> 
>> Alternative text suggestion:
>> 
>> A decision to send a Do Not Track signal SHOULD be based on the
>> affirmatively expressed preference of the user. In general the signal
>> SHOULD only be sent by a user's agent, and SHOULD NOT be modified by any
>> intermediary.
>> 
>> There are some situations where an entity other than the user wishes to
>> express a Do Not Track preference on the user's behalf. Such situations
>> may include those where the user has designated another person as their
>> system's administrator, such as in a shared computing environment like
>> an employer's network, or a public-use computer system like a library.
>> If a non-user wishes to express a Do Not Track preference on a user's
>> behalf, this SHOULD be done by configuring the user's agent to send the
>> desired signal.
>> 
>> Intermediaries to an HTTP(s) connection SHOULD NOT modify, add, or
>> remove a DNT signal sent by a user's agent. There may be limited
>> situations where an intermediary reasonably acts on a user's behalf. If
>> an intermediary modifies or sends a Do Not Track signal on the user's
>> behalf, and that modification or sending does not occur within the
>> user-agent, the scope of such modification should be as limited as
>> possible. Extreme care should be taken to ensure that any modification
>> accurately and completely expresses the user's preference. In
>> particular, the intermediary should take care to avoid disrupting user's
>> site-specific preferences and exceptions, and not to cause undue impact
>> to the user's browsing experience.
>> 
>> NOTE: it is understood that it is very difficult to technically verify
>> or enforce these provisions regarding intermediaries. They are included
>> to express what is and is not appropriate behavior for all participants
>> in the web ecosystem.
>> 
>> On 11/30/2011 09:57 AM, Shane Wiley wrote:
>>> Here is a draft for Issue-95 (http://www.w3.org/2011/tracking-protection/track/issues/95):
>>> 
>>> "Generally, the setting and/or unsetting of a Do Not Track signal SHOULD only be established by a user proactively.  Intermediaries to an HTTP/S request SHOULD NOT attempt to modify the DNT signal in any way.  There are limited situations where it MAY be appropriate for an intermediary to modify a user's DNT settings on their behalf such as through employer networks or public networks (libraries, for example).  But, care should be taken even in these cases to limit the scope of modification as much as possible to decrease the possible impact to a user's web surfing experience as overriding DNT signals could disrupt content consumption through user granted site-specific exceptions.  NOTE - it is understood this particular compliance standard cannot be technically enforced but it should be clear to all web ecosystem participants what the standard baseline is in this matter."
>>> 
>> 
> 
> 
> 
> 
> 
>

Received on Tuesday, 20 December 2011 16:52:30 UTC