Re: Today's call: summary on user agent compliance

On Jun 8, 2012, at 4:12 PM, Bjoern Hoehrmann wrote:

> * Shane Wiley wrote:
>> That is the sticking point here.  The standard is voluntary but we still
>> want a large majority of 3rd parties to implement DNT.  If we require
>> that supporting W3C DNT also requires accepting non-compliant UA
>> signals, I can't see a reason why many, if any, 3rd parties would
>> implement.  If we're setting up a "failed start", then I'm at a loss for
>> our path as a Working Group.
> 
> I think the DNT specifications need to say that the DNT signals can and
> must be taken at face value, including the absence of such signals.

I think you are missing the point.  The DNT signals do not matter if
the UA's implementation is broken.  A site can choose to do anything
it wants, including denying all service, provided that what it chooses
to do is consistent with other claims it has made to this user.

The same would be true if a UA decided to send "DNT: 0" by default.

I imagine the best response will be a single letter in the tracking
status that says the user agent is not supported for DNT, which
then instructs the user to follow the control link to an opt-out
mechanism based on cookies.  A site is not responsible for the
bugs deployed by browser companies.

If the service has the ability to supply or overlay content on
the page, it might go further and render a piece of content that
informs the user that they are using a non-compliant browser,
along with a link to a hypertext page that describes an opt-out
mechanism that is not subject to browser bugs, along with pointers
to browsers that aren't so buggy. This is no different than dealing
with old versions of browsers that have no support for DNT: a
non-compliant user agent will not accomplish what the user wants.

None of this matters in the EU, of course, since sending or not
sending DNT (or removing an invalid DNT) makes no difference to
the legal requirement of prior explicit consent.  Likewise, if
folks in the US want a stricter default, then they will craft
legislation for our representative government to create a stricter
default in the absence of DNT.  I am fine with anything that
creates a level playing field and does not abuse the protocol
for the financial benefit of one company.

> If you start with the second guessing, you will have to answer questions
> why you exercise or reserve the right to second guess in one case but
> not in some other case, and that will lead to pain and suffering.

That doesn't seem to be a problem.  

> I do not think there will be notable cases where user agents send non-
> compliant DNT signals under normal circumstances; the user agent vendor
> will rather argue that they are compliant, while others dispute that,
> and there is currently no proposed mechanism to resolve that dispute.

People can argue what they want, but that doesn't make them compliant.
The standard doesn't have to resolve that dispute -- it just has to
state the standard in (hopefully) unambiguous terms.  In cases where
there is a question regarding whether something is compliant or
not, the relevant authorities usually bring in experts to testify.
Such is the nature of any technical disagreement.

> It is possible that platform and browser vendors would be willing to
> subject themself to some veto mechanism where they won't ship or revise
> their user interfaces if tracking organizations do not like their user
> interface decisions, which would resolve such disputes, but that's very
> much out of scope of this Working Group as chartered, and not so likely.

Yes, it is out of scope.

> I note that Internet Explorer 9 for instance will prompt users on first
> use whether they accept, or not, or want to decide later, whether to use
> the "recommended" security and compatibility settings. If Firefox had a
> similar prompt and would throw in a DNT:1 recommendation in the dialog,
> there would be similar complaints, even though I would find that in com-
> pliance with any specification the Working Group could come up given its
> limitations on making user experience requirements.
> 
> I do not think there is a big difference between that kind of prompt and
> an outright default. Similarily, in the longer term, I would expect that
> platform, read: operating systems, vendors will allow users to make more
> "bundled" privacy decisions, like to turn on DNT for browsers and "apps"
> running on the system. Someone feeling strongly about "privacy" may want
> a general OS-level prompt they can use so applications stop asking them
> if they are okay with sending crash reports, stop offering to particpate
> in UI studies, stop storing their Wifi passwords in the cloud, and so on
> and such a setting may similarily turn on DNT in the platform's browser.

All that is needed is a choice made by the user (not the OS
vendor, the browser vendor, nor the sysadmin installing the OS).
That's not a high bar.

> The Working Group as currently chartered cannot make that obviously non-
> compliant, so I see non-compliant DNT signals as a red herring for this
> Working Group. As above, it would be better to simply define that DNT:1
> is, by definition, the user's preference, and tracking organizations are
> better off opposing DNT altogether if browser vendors make unreasonable
> user interface decisions where DNT signals don't reflect user decisions.

That doesn't make any sense.  Companies have already implemented DNT
on the basis that it reflects user choice.  DNT is already defined as
an expression of the user's choice.  If a UA decides to send the
header field without a user choice, then it is lying to the server.
It is breaking the semantics of HTTP.  We are not going implement
and revert, implement and revert, and so on based on the whims of
a single user agent.  We will exclude that user agent from receiving
any benefit from their duplicity.

If there is no choice, there is no implementation.  It is completely
absurd to expect that anyone would honor a DNT sent by default,
since the only reason to send DNT is to differentiate this request
from the default.  I don't expect anything to be said about it in
the specification other than in defining the semantics of the
header field.  There is no need to say anything more.

> There will be a Candidate Recommendation phase where the W3C calls for
> implementations of the DNT proposals and the Working Group will evaluate
> browser and "website" implementations of it, and compliance disputes, as
> they are known by then, can be resolved, or not, at that point. That'd
> be a better point to argue about possibly needed "escape clauses".

Compliance is not subject to WG review.  That is a review of what parts
of the spec have been implemented in practice.

> As I said earlier, if the Working Group cannot agree that "no means no",
> it is unlikely that there will be a Recommendation; and I've listed some
> of the options there are to turn "no means no" into "it's complicated".

I don't think the spec needs to say anything more on the issue because
compliance is voluntary.

> As for the specific issue of a mainstream browser that is pre-installed
> on a very large number of systems sending some DNT signal "by default",
> well, if the vendor doesn't mind to say that it's a default (as opposed
> to saying that users typically choose this browser explicitly because
> it's known to offer "strong privacy protections" or whatever), require
> them to make that explicit in the header and API. Let them send "DNT:23"
> until users "manually" confirm this default. That gets you around "users
> cannot activate DNT:1 explicitly in this browser" issue, and "browser
> sniffing" issues, and would give services that honour "do not track" in
> all cases an advantage over services that ignore "DNT:23" signals, pro-
> vided they don't fall into the same conformance class (they should not).

I doubt that will be submitted as a proposal, but it is certainly
an option that makes more sense than lying about "DNT: 1".

....Roy

Received on Saturday, 9 June 2012 01:12:17 UTC