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

[cid:BFCBD046-1E13-480A-AFA5-E415355FC13C]

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<mailto:michael.oneill@baycloud.com>>
Date: Wednesday, April 3, 2013 11:59 AM
To: 'Peter Swire' <peter@peterswire.net<mailto:peter@peterswire.net>>
Cc: "public-tracking@w3.org<mailto:public-tracking@w3.org>" <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: de-identification text for Wednesday's call
Resent-From: <public-tracking@w3.org<mailto: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<mailto: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<http://www.peterswire.net>

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