Re: TPE Handling Out-of-Band Consent (including ISSUE-152)

Allowing 53 weeks to look-up OOBC sounds extremely long.  Perhaps it makes
sense to place an outside limit on this kind of lookup of 48 hours, or even
a bit less.  Anything under 30 hours or so could be a problem for systems
that only gather OOBC confirmation on a 24-hour cycle.  There might be
other stakeholders I don't know about who have systems for which 48-hours
might be too short?

--ronan


On Fri, Mar 22, 2013 at 12:48 PM, David Singer <singer@apple.com> wrote:

>
> On Mar 22, 2013, at 3:19 , Rigo Wenning <rigo@w3.org> wrote:
>
> > David,
> >
> > what I see is the question who bears the risk of error. Ronan says: we
> > activate our data-vacuum-cleaner and expect the browser not to interfere
> > because 24 hours later we may be able to show out-of-band consent. If we
> > are unable, we will de-identify in some way.
> >
> > This basically raises the question how one can opt-out of an unknown
> > state. I think there are two ways depending on who takes the higher
> > risk:
> >
> > 1/ Ronan's vacuum-cleaner makes sure they have the consent they need and
> > indicate that by storing an exception and getting DNT:0 behavior. If
> > they have stored exceptions where they had no consent, the watchdogs
> > will go after them. Risk is on their side.
>
> I don't think Ronan is asking for an exception from the users he wants to
> track.  I may have it wrong, but I think he wants to say:
>
> "I might have out-of-band consent from you; I am going to collect the
> data, and within 53 weeks I will separate the data of those for whom I do
> not have consent, and discard it, and retain after that the data for those
> who did give consent; there is no way other than finding the original
> consent agreement for you to know which class you are in, or change your
> mind, and nothing online in the transaction or site will give you a clue
> where this consent might have been given."
>
> >
> > 2/ The browser basically allows for all collection and tracking
> > technologies even under DNT:1 and at some point someone may go to some
> > URI to find out whether there was consent. Or perhaps not even that.
> > Risk is on the user's side.
> >
> > I think in Ronan's scenario, they should signal "C" and take the risk of
> > overstating while cleaning out their base ASAP. On the long run, they
> > will have to think about how to handle DNT:1 users and whether they want
> > to leverage the DNT signal for their system which would remove the
> > uncertainty. Because they could determine at any moment in time whether
> > they have consent or not. They could just look it up in the browser in
> > real time via the API.
>
> The claim, as I understand it, is that they cannot look it up in anything
> close to real-time.
>
> I think the potential for abuse of what I have written above is rather
> concerning. Even a hypothetical situation where they signal "possible
> consent", and offer a URI where the user can find out whether the site
> thinks that they have consent, and allows the user to change their mind,
> feels…uncomfortable…and that's not what is being asked for, as I understand
> it.  This is what Shane suggests (well, he suggests merging "I claim I have
> consent (C)" with "I might have consent, let me check" (for which I would
> suggest a different character)):
>
> On Mar 22, 2013, at 6:42 , Shane Wiley <wileys@yahoo-inc.com> wrote:
>
> > The working group appeared to agree to use the “L” for not listening
> based on this week’s call (“!” will be used to signal something different).
>  How about stick with “C” but name it “Conditional” with a resource link to
> explain what that means in your context?
>
>
> A 'debugging' UI should be possible, even if it's not often used.  The
> conformance people at industry associations should be able to 'crawl' their
> members's online presence and confirm that they seem to be upholding the
> standards of the association and the reputation of the industry for
> transparency and accountability.  I don't see how to get there with this
> problem, yet.
>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
>