de-identification text for Wednesday's call

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.





From: Peter Swire [] 
Sent: 03 April 2013 14:13
To: Rob Sherman;
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.








Professor Peter P. Swire

C. William O'Neill Professor of Law

    Ohio State University



From: Rob Sherman <>
Date: Wednesday, April 3, 2013 12:32 AM
To: "" <>
Subject: ACTION-273/ISSUE-181: Multiple First Parties
Resent-From: <>
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,  Example Analytics
measures usage of and provides Example News with aggregate data
regarding that usage. is branded with the 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


A final issue that we've been discussing is the issue of multiple parties
operating on a platform - the 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

Received on Wednesday, 3 April 2013 16:00:25 UTC