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

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) <
mts-std@schunter.org> 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 <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.
>>
>>
>>
>
>


-- 
Edward W. Felten
Professor of Computer Science and Public Affairs
Director, Center for Information Technology Policy
Princeton University
609-258-5906           http://www.cs.princeton.edu/~felten