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

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

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.

Received on Wednesday, 25 July 2012 15:54:59 UTC