- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 26 Apr 2013 13:59:11 -0700
- To: Nicholas Doty <npdoty@w3.org>
- Cc: Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
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