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

Hi!

I believe
- that out-of-band consent will co-exist with in-line consent/exceptions 
for a while
- that it is technically hard to dynamically look up out-of-band consent 
in real-time (before returning HTML).
- that a signal like "'c': I will process your data according to the 
out-of-band consent stored in our systems" makes sense

The conditions that seem to evolve from a privacy perspective are:
- Transparency: Users should get a final information whether their DNT;1 
was respected (and the data cleansed)
    or else an explanation what OOBC was used and where it came from
- In this scenario, additional documentation at the "control" link would 
be required
- Privacy: The retention period in this scenario should be rather short 
(ideally not longer than the time you can
    keep any data temporarily; 43 weeks is out of the question.
    We can also keep it flexible by
       (a) by default not exceeding the permitted retention for any data 
(btw. I do not know whether this has been fixed in the compliance spec yet)
       (b) allowing a documented retention period up to 48h if the 
company documents why this much time is needed
            (e.g., saying that their databases are synced every 24h and 
therefore a reliable output that includes recent changes requires 30h)


Opinions/Feedback?

Matthias

  On 22/03/2013 18:04, Ronan Heffernan wrote:
> 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 
> <mailto:singer@apple.com>> wrote:
>
>
>     On Mar 22, 2013, at 3:19 , Rigo Wenning <rigo@w3.org
>     <mailto: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
>     <mailto: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.
>
>
>