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

Hi Ed,

thanks for asking.

The flow that I had in my mind was:
  0. A user visits a site with DNT;1
  1. The site answers "c"
  2. In this case a "control" link is mandatory
  3. The user visits the control link (and by doing so reveals the same 
info as in STEP 0; can be a login or a cookie or something else)
  4. The site retrieves the OOB consent based on this information and 
returns it to the user
      This may come with a disclaimer: "If you changed preferences in 
the last 24h, this info may not be accurate" or "We retrieve the 
information within the next 24h;
      if you visit this page again after [time], we will provide the 
requested info to you".
  5. The site either says "we did not receive OOB consent and respected 
DNT;1 and have cleansed the data" or else "We have OOB consent 
[additional info is a plus]
      and therefore assumed that you are OK with us disregarding your 
DNT;1 signal."

With transparency I mean that step 5 is guaranteed to return a correct 
reply (or err on the side of cleansing: It is OK to cleanse despite 
having OOB consent).

The max time between steps 0 and 5 should be reasonably short (ideally 
shorter than the time you can keep data temporarily anyway).

Does this answer your question? Any feedback is appreciated...


On 26/03/2013 19:50, Edward W. Felten wrote:
> How would your "Transparency" condition be met? It would seem to 
> require the site to contact the user later to inform them of whether 
> the site had OOB consent from them.   I'm not clear on how the site 
> would be able to contact the user later.
> On Tue, Mar 26, 2013 at 2:26 PM, Matthias Schunter (Intel Corporation) 
> < <>> wrote:
>     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 <
>>     <>> wrote:
>>         On Mar 22, 2013, at 3:19 , Rigo Wenning <
>>         <>> 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 <
>>         <>> 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.
> -- 
> Edward W. Felten
> Professor of Computer Science and Public Affairs
> Director, Center for Information Technology Policy
> Princeton University
> 609-258-5906 
> <>

Received on Tuesday, 26 March 2013 19:11:50 UTC