- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Tue, 26 Mar 2013 20:11:24 +0100
- To: "Edward W. Felten" <felten@CS.Princeton.EDU>
- CC: "<public-tracking@w3.org>" <public-tracking@w3.org>
- Message-ID: <5151F2DC.6090906@schunter.org>
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...
Regards,
matthias
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)
> <mts-std@schunter.org <mailto: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
>> <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.
>>
>>
>>
>
>
>
>
> --
> 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
> <http://www.cs.princeton.edu/%7Efelten>
Received on Tuesday, 26 March 2013 19:11:50 UTC