Re: ISSUE-4 and clarity regarding browser defaults

On Jun 4, 2012, at 5:41 PM, Bjoern Hoehrmann wrote:

> * Roy T. Fielding wrote:
>> I have added text based on Aleecia's original proposal that was
>> reviewed in Santa Clara (IIRC), slightly modified to reflect the
>> three alternatives (unset, on, off) we agreed upon and to fit
>> within the determining/expressing/multiple-mechanisms order of
>> the current spec.
>> 
>> http://lists.w3.org/Archives/Public/public-tracking-commit/2012Jun/0000.html
> 
> Aleecia's text required user agents to offer DNT:1 and DNT:0 to users,
> while your text requires user agents to offer DNT:1 and no header. I am
> not aware the Working Group has decided that offering DNT:0 would be
> optional. I think making "DNT enabled but off" optional requires a spe-
> cific decision that can't be read into decisions regarding ISSUE-4.

Aleecia's proposal first says they MUST offer two options and then says
a third option (unset) is required by default, which was pointed out
as a contradiction later on (I can't remember if it was in email or
at the F2F just a few days later).  You will see mention of it in
several other mails as a tripartite state.  I reduced the requirement
on offering "DNT:0" because that would make all of the current browser
implementations non-conforming and I am certain we talked about that
as being an option, not a requirement.  In general, I find the way those
sentences are worded to be problematic due to the UI concerns, which
is probably why I didn't include them the first time.

The goal of the current text is to match the resolution of ISSUE-4.
I only used Aleecia's email as a guide to figure out what was missing
between that resolution and what we had in the last WD.  My concern
is that the resolution for ISSUE-4 be represented faithfully in the
specification, not that it exactly matches the original proposal.

> I think it is misleading to say that "A user agent MUST have a default
> tracking preference of unset (not enabled)" which you can easily quote
> out of context as I am doing here, omitting the following "unless" part.

That's not a problem.  "unless" is a pretty clear conditional.

> Similarily, the following text "For example, use of a general-purpose
> browser would not imply a tracking preference when invoked normally as
> SuperFred..." could be read to mean that GNU IceCat cannot use `DNT:1`
> by default, even though, as far as I can tell, it is a general-purpose
> browser, presumably known to implement "privacy" features that go above
> and beyond what mainstream browsers do, simply because of its name. I
> do not think the Working Group has decided that, in effect, IceCat can't
> use DNT:1 by default. "Iron" would be a similar example, a fork of a
> general-purpose browser, as far as I can tell anyway, but quite assumed
> to have additional privacy features compared to what it is forked from.

I think that is already reflected in the text.  It isn't the name
that matters -- what matters is the choice made by the user.

> (Given that the Working Group has decided that "user experience" is out
> of scope, I am afraid I can't make suggestions how to improve the text.)

Yep, I had that problem too.

> I also note that "default" assumes the absence of an explicit prompt...

I am not quite sure what you mean.  If there is an explicit prompt,
I would hope that the initial option is unset unless the choice
of browser/extension was already a clear choice for a different
default.  If the user selects something when prompted to indicate
their choice, then we are no longer talking about a default.

To be clear, I don't expect failure to meet any of these conditions
to be detectable by a server. They only exist to define the semantics
of what DNT means when it is sent. If the semantics are wrong,
I expect people to discover that, complain, and add logic of their
own to deal with the broken UA.  Likewise, I would expect the same
people to include, in their description of "DNT compliance", a
caveat that lists specific UA versions for which DNT won't be honored.
None of that needs to be in the protocol spec.

....Roy

Received on Tuesday, 5 June 2012 01:57:41 UTC