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

I'm not clear on the purpose of the 'c' flag.  If the site can provide an
answer on the control page, why can't it provide the same answer directly
to the user, without requiring the user to interrupt the flow of their
browsing to visit a control page on a third-party site?

It doesn't seem reasonable to require the user to potentially visit a
third-party site twice, just to find out what the site's DNT compliance
status is.    It also seems technically challenging for a third-party site
to be able to identify such a user over time in a case where the user isn't
logged in.   How can the site reliable connect a user's visits over time in
the scenario you describe?   We can't assume that third-party cookies will
be preserved, nor should we require users to accept and maintain cookies in
order to opt out of cookie-based tracking.


On Tue, Mar 26, 2013 at 3:11 PM, Matthias Schunter (Intel Corporation) <
mts-std@schunter.org> wrote:

>  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> 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
>
>
>


-- 
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