Re: Moving "C"onsent from Tracking Status to Permitted Use?

[Summarizing some off-list back-and-forth with Mike O'Neill:]

I do not think that OOBC is going to be a "transitory mechanism".  The
in-band exception API will not be usable in a great many cases.

For every publisher (major website operator), we have to ask if they will
allow us to send JS to browsers when we are a 3rd party on their site.
Some providers, especially major providers, tell us "No".  In that case, we
have to use image-based content, not JS-based content.  That disallows  a
few of our advanced features, and will prevent any JS-based API
interaction.  I understand their position; if I ran a major website I would
be wary of allowing 3rd parties to inject JavaScript that could screw-up
the appearance or otherwise degrade the user experience on my site.

We will also not be allowed to "link-off" to another page to get consent.
Publishers will not want *their* users leaving *their* site to go
grant/deny exception to third parties.  If there is a control link or
request for consent in the HTTP header, and that control link or question
is going to trigger a UA popup (or other on-screen element), we will be
forbidden by most major publishers to exercise that feature.  They didn't
spend hundreds of thousands of dollars designing a beautiful (and "sticky")
website to have a bunch of 3rd party user-interaction destroy the user
experience.  The popups will scare uninformed users and destroy the
aesthetics of the site/visit for other users.  So in reality, on most major
websites, research companies and other third parties will never get the
opportunity to exercise the in-band consent mechanism, or even declare
their existence in any way that will result in major UAs putting anything
in the user's face. We will have to operate without being able to interact
with users.

One important solution to these problems is OOBC.

--ronan


On Thu, Mar 28, 2013 at 9:40 AM, Mike O'Neill
<michael.oneill@baycloud.com>wrote:

> I think this also solves Adrian's use case, as far as I understand it,  of
> establishing consent across devices, i.e. by a user clicking a link in an
> email.
>
> If the server can recognise it has OOB consent for this user (using a
> cookie
> probably or a unique URI ) then it can convert it in-band as soon as it
> can.
> i.e. by calling the API if the response is HTML or encouraging the user to
> go the domain as a 1st party. There will need to be a way to get round
> third-party default blocking (which is becoming the norm) and the consent
> API is the best way to do that. OOB response headers might not be good
> enough, except for the first time, because it is not as transparent or as
> simply revocable.
>
> There should be non-normative text recommending this so OOB consent is
> positioned as a transitory mechanism rather than a replacement for the API.
>
> Mike
>
>