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

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

From: イアンフェッティ <ifette@google.com>
Date: Wed, 22 Aug 2012 08:59:20 -0700
Message-ID: <CAF4kx8eTS-hx0n8h=Thz_NZ7=XaVFnqxz9vYWtDd=wJWP3D8oA@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
On Wed, Aug 22, 2012 at 8:44 AM, David Singer <singer@apple.com> wrote:

>
> On Aug 22, 2012, at 6:43 , David Wainberg <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.comand
> 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.
Received on Wednesday, 22 August 2012 15:59:55 UTC

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