RE: de-identification text for Wednesday's call

Hi Brooks,

 

I think you can still call for unlinking by IP address by requiring their
deletion by the data controller, i.e. administrative and operational
controls (AOC).

 

You would have to rely on these when these identifiers are long lasting,
i.e. static IPv4 addresses or other than temporary IPv6 ones. As things move
to IPv6 it will be less of a problem because temporary addresses will become
the norm.

 

I think we should have a separate definition of unlinkability because it
gives you a knob you can dial depending on the circumstances. You could
allow permitted uses, say audience measurement or financial audit, that
otherwise would be problematical. You could then keep the data for extended
periods, perhaps de-identified to remove PII, by making the data unlinkable
beyond a maximum period. For instance, in the case of UIDs in cookies you
could require they had a duration less than X and not allow cloning of the
UIDs. This has the advantage over purely AOC by being transparent (visible
in logs).

 

Mike

 

 

 

From: Dobbs, Brooks [mailto:Brooks.Dobbs@kbmg.com] 
Sent: 03 April 2013 17:24
To: Mike O'Neill; 'Peter Swire'
Cc: public-tracking@w3.org
Subject: Re: de-identification text for Wednesday's call

 

Mike,

 

I would suggest that "or be linked to" might be a problem.  Absolutely
anything could be linked to an identifier, which would seemingly preclude
absolutely everything from being de-identifed.  By way of example, the
redacted IP address 208.x.x.x would not (IMHO) be identified by any
reasonable standard, but obviously retains the ability to be linked to
identity.  

 

I am guessing what you are really thinking of here is a 1:1 linkage as
opposed to a many:1 linkage.  If I am correct, is there a better way of
expressing this?

 

-Brooks

 

 

-- 

Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com 
brooks.dobbs@kbmg.com



This email - including attachments - may contain confidential information.
If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message. 

 

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Wednesday, April 3, 2013 11:59 AM
To: 'Peter Swire' <peter@peterswire.net>
Cc: "public-tracking@w3.org" <public-tracking@w3.org>
Subject: de-identification text for Wednesday's call
Resent-From: <public-tracking@w3.org>
Resent-Date: Wednesday, April 3, 2013 12:00 PM

 

I like Roy's text, as his definition of identifying includes unlinkability.
To make this clear I would add the clause ",or be linked to,"  as below:

 

Data can be considered sufficiently de-identified if there exists a
reasonable level of confidence that the data cannot be used to identify, or
be linked to, a particular user, user agent, or device.

 

Mike

 

 

From: Peter Swire [mailto:peter@peterswire.net] 
Sent: 03 April 2013 14:13
To: Rob Sherman; public-tracking@w3.org
Subject: Re: ACTION-273/ISSUE-181: Multiple First Parties

 

Rob and Justin:  I wanted to thank you for your work together on this issue.
The revised materials you have sent address all of the key issues that I
remember from previous discussion, and do so in a well-written and
constructive way.

 

On the call today, you can present this briefly, and we will see whether we
can have consensus to move to Pending Review-Stable on this.

 

Peter

 

 

 

 

 

Professor Peter P. Swire

C. William O'Neill Professor of Law

    Ohio State University

240.994.4142

www.peterswire.net

 

From: Rob Sherman <robsherman@fb.com>
Date: Wednesday, April 3, 2013 12:32 AM
To: "public-tracking@w3.org" <public-tracking@w3.org>
Subject: ACTION-273/ISSUE-181: Multiple First Parties
Resent-From: <public-tracking@w3.org>
Resent-Date: Wednesday, April 3, 2013 12:33 AM

 

One of the agenda items on tomorrow's call is evaluating text on multiple
first parties.  Peter circulated as a part of the agenda the two text
proposals - one offered by me and the other by Justin Brookman - that have
been suggested to cover this issue.  Justin and I have since spent some time
trying to bring these proposals closer together and have come up with this
language, which is offered for discussion:

In most network interactions, there will be only one first party with which
the user intends to interact.  However, in some cases, a network resource
will be jointly operated by two or more parties, and a user would reasonably
expect to communicate with all of them by accessing that resource.  User
understanding that multiple parties operate a particular resource could be
accomplished through inclusion of multiple parties' brands in a URI, or
prominent branding on the resource indicating that multiple parties are
responsible for content or functionality on the resource with which a user
reasonably would expect to interact by accessing the resource.  Simple
branding of a party that merely serves as a service provider to the single
entity providing a resource will not be sufficient to make that party a
first party in any particular network interaction.

We've also discussed an example (text to be finalized, but draft offered for
context) to illustrate this:

 

EXAMPLE:  Example News operates a news website, News.com.  Example Analytics
measures usage of News.com and provides Example News with aggregate data
regarding that usage.  News.com is branded with the News.com logo, but the
homepage also includes an indication that the website is "powered by Example
Analytics."  Despite this branding, only Example News would be a first
party.

 

A final issue that we've been discussing is the issue of multiple parties
operating on a platform - the Facebook.com/Macys example that we discussed
on our call.  Justin and I agreed that a reasonable approach in this case is
to treat the platform operator as the first party and the owner of the page
as a third party.  The main issue here is that users expect the platform to
share actions on the page with the page owner in a way that is consistent
with the platform's privacy policy.  We agreed that, because of the
disclosure in the privacy policy and the context of the user's interaction
with the platform, the page owner doesn't need to be a first party for this
to happen.  Assuming others agree on this point, Justin and I can work on
language to implement it.

 

One other wrinkle in the platform context is applications that are
essentially embeddable programs that happen to be accessible from within a
platform.  My sense is that we can handle this like any other widget/plugin
- third party until a user interacts, then first party - though Justin may
have a different view.

 

Look forward to discussing this on the call tomorrow.

 

Rob Sherman

Facebook | Manager, Privacy and Public Policy

1155 F Street, NW Suite 475 | Washington, DC 20004

office 202.370.5147 | mobile 202.257.3901