W3C home > Mailing lists > Public > public-tracking@w3.org > May 2012

Re: explicit-explicit exception pairs

From: Nicholas Doty <npdoty@w3.org>
Date: Wed, 2 May 2012 01:04:39 -0700
Cc: Rigo Wenning <rigo@w3.org>, public-tracking@w3.org
Message-Id: <936FD32A-7245-4C8C-8F2A-ECE3E668B2DF@w3.org>
To: ifette@google.com
On Apr 30, 2012, at 9:37 AM, Ian Fette (イアンフェッティ) wrote:

> I'm a bit perplexed as to the fact that you think a UI such as the one you describe would actually be compliant. I thought the whole point of this exercise was to allow the user to express a preference and translate that as directly as possible to something that can be passed on to websites they visit. 

Is the draft unclear about compliance? Text improvements are always welcome. In this case, the note:

"It is left up to individual user-agent implementations how to determine ... users' tracking preferences." 

was intended to give a lot of leeway to different user agents. (And it might have been user agent developers who came up with that particular phrase, they tend to like specs that give them choices on how to implement particular UI.)

> If you start picking and choosing from the API as if it were a buffet, where does that leave you? You seem to imply it's fine for a UA to ignore the explicit nature of a "first/third" exception and turn it into a "first/*". Would it be equally fine then to just ignore the distinction between "first/*" and "*/third" and just offer "site" exception regardless of first/third issues? Or just to ignore exceptions all together and say "Eeh, it's a UI issue, if the site grants an exception to anything we'll just turn off DNT globally."

I think the requirement is for the user agent to communicate the user's tracking preference, whatever they determine it to be. I suspect turning off DNT globally when a user granted a single exception probably isn't a very good determination of their preferences, but maybe you have different evidence about what your users want.

> I think what is being proposed is unworkable and people are trying to use the notion that it's "just a UI issue" to keep it in the spec. This is not a good idea. 

Well, that's not my intention at least; I honestly believe that allowing variation in UI among user agents is a good outcome.

> As for the new corner cases, I think many of us are expecting that there will be new regulatory considerations (either under existing or future regulatory regimes) that will involve DNT. Whenever there are new considerations, there are new corner cases. For instance, cookie blocking doesn't actually send any explicit signal to the server, nor does the server have any clue as to what the heck is actually going on. Now we're giving servers a clue, hence there's much more complex considerations.

I'm not sure I understand the issue yet but I would be very interested to hear more about this. (Does a self-regulatory opt-out cookie give the server an explicit signal?)


P.S. Phew, sorry all for the flood of emails, just wanted to try to catch up before our call, now a mere 8 hours away.

> On Mon, Apr 30, 2012 at 12:24 AM, Nicholas Doty <npdoty@w3.org> wrote:
> On Apr 25, 2012, at 8:21 AM, Ian Fette (イアンフェッティ) wrote:
> > Also, I don't think we should just punt something by saying "It's a UI issue." The spec has implications on UI that should not be ignored. explicit/explicit means we have to come up with UI to support this, where so far we have failed, it means sites now have to worry about corner cases they didn't before, etc.
> I agree with Rigo that this is a UI issue in the sense that user agent developers are completely free to decide whether or not to create what kind of UI they want. (We were able to discuss this confusion in DC, but only briefly, so I'll try to recap.) If Google Chrome decides that its users never want or need to see a list of domains, even when a site requests exceptions for a specific list, Chrome need not present any such UI; the browser can just display whatever UI the Chrome team creates for a site-wide exception and the team doesn't have to come up with any other UI. The browser also may choose not to store the list version of the permissions but just store a site-wide permission, or not to store the permission at all, the spec explicitly leaves all of these choices up to the user agent implementation. (Section 6.5 lists several other UI decisions that are also completely up to the user agent developer.) I expect user agent UIs to vary -- some browsers will use a simple built-in UI to avoid burdening their users; a developer of plugins for particularly privacy-conscious users might build a more complex configuration panel. Vive la différence.
> What are the corner cases that sites have to worry about that they didn't before? In the current self-regulatory opt-out cookie system the publishing site never gets an indication of whether one of its advertisers received an opt-out signal (unless it communicates on the server side) and the site may have a mix of advertisers that received opt-out cookies or not. Sites that only wish to ask for site-wide exceptions can always call requestSiteSpecificTrackingException with the "*" parameter; that some unrelated sites specify a list of origins in the parameter need not affect them. Of course, even sites that always use "*" may still receive visitors where some of their parties receive DNT:0 and others receive DNT:1, but that situation will exist whether the JavaScript API takes a list parameter or not.
> Hope this helps,
> Nick

Received on Wednesday, 2 May 2012 08:04:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:42 UTC