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

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

From: David Singer <singer@apple.com>
Date: Wed, 22 Aug 2012 09:12:15 -0700
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Message-id: <1F51C981-1F15-4926-AA4C-0EC4C5BE5F65@apple.com>
To: ifette@google.com

On Aug 22, 2012, at 8:59 , Ian Fette (イアンフェッティ) <ifette@google.com> wrote:

> 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 :)

Ah, I have not researched Firefox's approach.  I assume you would set a 'suitably broad' cookie (e.g. *.google.com) and yes, if you have unrelated domains, some re-direct trickery might be needed.

>  
> 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.

> 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.

Well, I think that they exist as a 'weak' alternative to in-band.  I am honestly unsure as to what use-case they are satisfying, except maybe simplifying a user experience where the API 'check' is truly redundant.

I don't think anyone *has* to use out-of-band exceptions, so if they are awkward for you and in-band is not, use in-band.

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 22 August 2012 16:12:49 UTC

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