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 Monday, 19 December 2011 12:19:03 UTC