RE: ACTION-222 (Document out-of-band js api)

Ian,

In Seattle we had agreed the Server can send the OOB Exception to the UA so it can be recorded there (if the UA supports that feature).  This would still give users a single place to make all of their exceptions – where driven by the UA or the Server.

- Shane

From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com]
Sent: Wednesday, August 22, 2012 8:59 AM
To: David Singer
Cc: public-tracking@w3.org Group WG
Subject: Re: ACTION-222 (Document out-of-band js api)

On Wed, Aug 22, 2012 at 8:44 AM, David Singer <singer@apple.com<mailto:singer@apple.com>> wrote:

On Aug 22, 2012, at 6:43 , David Wainberg <david@networkadvertising.org<mailto:david@networkadvertising.org>> wrote:

> Does it even have to change the DNT signal? I'd think all it has to do is store the exception -- a single value -- and then transmit back to the server the fact than the exception is present. Ideally, it would be sent in the header, accompanying the DNT signal. All the logic of what to do with it is in the server. The UA doesn't have to think at all about the if or when it alters the DNT.
I thought that the meaning of out-of-band exception was one that was not negotiated using the exception API.  The canonical example is a site that can correctly state that the mere fact of being you logged in gives it an exception, a permission to track (e.g. TrackMyReading.com which tracks you through the pages you visit and the ILikeToReadThis buttons you click).

I thought the terminology was:

in-band exception -- negotiated with the user, and then confirmed using the exception API, and then signalled by the UA (in-band)
out-of-band-exception: negotiated with the user in some way outside this specification (out of band), and then claimed by the site without the involvement of the UA


There was an open question as to whether "out of band" should mean wholly without any involvement of the UA, or whether it was just without any UI from the UA. If it's wholly without the involvement of the UA, it may be impossible to remember the fact that you have an out of band exception.

>
> On 7/25/12 11:54 AM, Ian Fette (イアンフェッティ) wrote:
>> I think we have two ways to go with an out-of-band consent mechanism. This is largely necessitated in my mind by the fact that a significant percentage of users (mostly because of default browser settings and/or add-ons, but also including some number of users who have explicitly configured their settings in this way) block third party cookies. If third party cookies are blocked, a third party site has no way of remembering that they have an OOB exception, as they can't place a cookie on the computer saying "by the way, this user has granted an OOB exception".
The blocking of third-party cookies by Safari blocks the *setting* of new cookies, but existing ones are returned.  So if you negotiate an exception when the user visits the site (which is the way to do it) you *can* set a cookie then, and it *will* be returned to you when you are a third party.  (At least for Safari, afaik).

So I would have to redirect through potentially multiple domains and set a cookie on each? what about firefox, where IIRC third party cookie blocking blocks cookies from being sent but not set? (even if it was set in a first party context)? This is all wonderfully non-standard :)


>>
>> 1. The exception mechanism could do nothing more than switch from DNT:1 to DNT:0 for the site. The browser should probably stay out of the way, UI-wise, and just store the exception when a website notifies the browser that it believes the user has consented to an out-of-band exception. If the browser pops up UI, then it's not really out-of-band. A passive indicator might be fine here such that users who are highly concerned get transparency into the fact that this is happening, but nothing that would require interaction for the out-of-band exception to be stored.
>>
>> 2. The exception mechanism could do more than switch from DNT:1 to DNT:0, such as enabling third party cookies for that origin (which seems reasonable if the user has opted-in on that site). In this case I would prefer that the UI were still passive (gives people a way to audit what's going on and whack people who are using this inappropriately), but depending on how much additional power is given to a site (just storing cookies, or more?) I could see "active" UI that a user has to interact with being involved here...
>>
>> Either way, I think we also need to let a site define what it believes is part of the "same party" here. e.g. if a user has given an out-of-band consent to google, we would want to be able to get https://www.google.com and http://www.google.com at the same time, etc.

How you pass *out of band* exceptions around is, well, out of band, unless I have the model wrong.  We are currently debating whether to use fully-qualified domain names, or allow leading wildcards (cookie-style) for in-band exceptions.  But at the moment, the protocol name does not enter into it;  the agreement is between a site and a user, and it doesn't matter what protocol is used (except we currently only have a way to signal DNT in HTTP).

David Singer
Multimedia and Software Standards, Apple Inc.


I think the problem is that it's easy to envision a world where you might have no way to store an out of band exception. If we're going to rely on this mechanism, we need to ensure that it actually works.