Re: Issue-4

On Oct 27, 2011, at 12:11 PM, Tom Lowenthal wrote:

> ### Scope ###
> 
> Section 1.2 of our charter ("Out of Scope") states:
> 
>> "While guidelines that define the user experience or user interface
> may be useful (and within scope), the Working Group will not specify the
> exact presentation to the user."
> 
> It is not this group's job to define how a user's agent should present
> this feature to the user. We should define the criteria for compliance,
> and the technical mechanism of expression. After that it is the
> responsibility of the user's agent to accurately determine that user's
> needs, and whether this user would prefer that this particular signal be
> sent.
> 
> One option might be an checkbox in the browser's privacy settings, which
> the user has to find and check. Another option might be Aleecia's
> suggestion of a privacy slider. A super-duper-privacy-protecting browser
> might always send the header. Some savvy users might use an older
> browser, but manually add the header via a proxy on their machine or
> their local network. In the year 2142, your personal robot may interview
> you about your preferences and choose whether to send DNT based on its
> assessment of your needs.
> 
> My point here is that talking about the defaults or the way that this
> feature may be presented to users (if agents even choose to explicitly
> present it at all) is a red herring. It's a browser's job to give a user
> the web how that user wants it, and the UX teams at browsers are
> infinitely more qualified to build an interface which accurately
> interprets users' needs than this group is.

I agree the UX bit is a red herring -- the draft already says that the
UX is entirely defined by the browser.  That, of course, has nothing to
do with whether the default is on without the user's affirmative action
(before the user has experienced anything).

> ### Default Reaction ###
> 
> With regards to Roy's point on the call yesterday, and later Rigo's
> email, from a protocol perspective, it doesn't matter what a browser's
> default settings are. On day one of our first meeting, we agreed the
> following points:
> 
> - When a server receives a header of "DNT:1" DNT is on.
> - If a server does not receive that header, DNT is not on.
> 
> This is quite adequate from a server's perspective. Given receipt of a
> particular signal, they know how to respond. Further, a site does not
> need to know *how* a browser interrogated their user to determine that
> user's preference, only that they did, just like with every other signal
> sent by the browser.

It's never that simple.  Servers have many workarounds for buggy or
irresponsible clients, just as clients have many workarounds for
buggy or irresponsible servers.

As a server developer, I can state quite confidently that a feature
which is enabled by default is not a user's preference unless the
reason for installing that software is the preference.

So, for example, if I know Mozilla has the default "on" just because
one of the open source developers thought that is the way it should be
for Mozilla, then I would ignore that setting of DNT because there is
nothing to suggest that it reflects the user's expression.  If, however,
the setting came from Mozilla-Ultra-Stealthy-Edition and I know that
user's have installed it for that purpose, then I would respect such
an expression.

> ### "Network Neutrality" ###
> 
> I think we all agree that we don't want to see the behavior where an ISP
> forges DNT headers from its users unless it gets protection money.
> However, we don't want to rule out users who might set DNT via a local
> network proxy or similar technical means. We might also imagine a small
> ISP which differentiates itself on its robust privacy features, and
> offers a control panel where users can universally switch DNT on or off
> for their own connection. I don't think we want to prevent this sort of
> innovation.
> 
> In light of this, language prohibiting entities other than the browser
> from setting DNT does not seem preferable, in addition to being about as
> effective as standing on the beach and telling the tide not to come in.
> Rather, I suggest language like:
> 
>> The DNT header **must only** be added, removed, or modified based on
> the known preference of the user.
> 
> But leaving it up to any entity or piece of software to determine
> exactly what their best method is for asking the user what they want.

That's fine with me.

....Roy

Received on Thursday, 27 October 2011 22:38:55 UTC