Re: Using a standard cookie for opt-in exceptions (was: TPE sec 6.11 on clearing granted exceptions)

On Apr 26, 2013, at 1:26 PM, Nicholas Doty wrote:

> We considered magic cookies when Roy proposed them in Santa Clara, November, 2011.
> http://www.w3.org/2011/11/01-dnt-minutes.html
> 
> As I recall (and as I understand the minutes) we did not prefer that approach. Browsers aren't exactly sure how to treat these magic cookies (would they always be cleared with other cookies?), it overloads the mechanism, and may not express the same clarity of affirmative consent.

I believe that I have already explained that.  Since the UGE is now
governed by a site-based UI, the last concern is no longer relevant.

> And John Simpson wrote up some text to the mailing list:
> http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0084.html
> ... with largely negative responses in the subsequent thread (technology specific, not all devices may use cookies, DNT users may often clear cookies).

Those responses were about limiting consent to one mechanism.
Javascript APIs (behavioral) are far more technology specific than
cookies (declarative). Devices that don't allow cookies are not
going to run javascript either. And the default clearing behavior
is what we want for the default -- more advanced clearing (or
not clearing) can be deployed over time.

> Using cookies instead of DNT:0 also makes it difficult, perhaps impossible, for first party sites (which we expect to be the one requesting these site-wide exceptions) to install them for every third party on their site. That is, if you're a publisher, and you ask your visitor for permission for third party ad networks on your site to track the user, cookies can't handle that communication. That was always an explicit goal of user-agent-managed exceptions, to avoid the need for additional standards for server-to-server communication to imply that this user really does have an exception.

As I said, such communication is normally done within the URI used
to make an ad or auction request.  Doing it using unimplemented APIs
is a nonstarter -- it can't be relied upon.  When we are talking about
features that impact core revenue for sites, there isn't a lot of
appetite for experimentation on non-deployed features.

> And it creates the potential for mixed signals, as in Roy's example below. (Rather than sending you DNT: 1 and Cookie-DNT: 0, why not just send DNT: 0? Or, in the more common case, a third party receives DNT: 1 and some other signal through a URL parameter or server-to-server communication from the first party indicating that they got an exception.)

The signals are intentionally mixed -- that is what we want.
A general preference plus an exception, as opposed to losing the
general preference when we add an exception.

> I suggest we continue with DNT:0 rather than magic cookies, as I understood we had previously decided.

The WG didn't decide anything.  We just didn't pursue the direction that
I suggested, which is rarely a good thing when we are talking about
what can be deployed over HTTP.

As a site implementor, I already know that we won't be implementing
the javascript exception APIs described in the current TPE.  They
are too complex, too dependent on browser behavior, and won't be
deployed correctly in the foreseeable future.  Hence, they are a
waste of time given the intended timeline for our work.

....Roy

Received on Friday, 26 April 2013 20:59:25 UTC