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

Roy,

A consent mechanism (aka UGE) is a good thing because it signals user
consent. UAs could use it to raise third-party cookie blocks and regulators
can detect it in logs. We may not need a JS API for this, as long as it is
not too easy to bluff. How about UAs only lift a third-party cookie block if
the w3cdnt=0 is set by a first-party (script or HTTP). They have to detect
first-parties anyway (to recognise a third-party cookie). 

So if the Do Not Track general preference is set UAs MAY set a third-party
cookie block. If a top-level origin sets the cookie w3cdnt=0 UAs MAY lift
the block for distributary third-parties. 

If w3cdnt is deleted (or expires) then local law prevails.

Mike


-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 26 April 2013 21:59
To: Nicholas Doty
Cc: Rigo Wenning; public-tracking@w3.org (public-tracking@w3.org)
Subject: 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 22:08:15 UTC