SEPTEMBER 2019

C H A R T I N G A WAY F O R WA R D

Data Portability
and Privacy

Erin Egan
VICE PRESIDENT AND
C H I E F P R I VACY O FFI C E R , P O LI CY
C H A R T I N G A WAY FO R WA R D

1

Table of Contents

03 I. Intro
06 II. The Challenge
09 III. Five Questions About Portability and Responsibility
09 Q U E S T I O N 1

What is “data portability”?
13 Q U E S T I O N 2

Which data should be portable?
14 Q U E S T I O N 3

Whose data should be portable?
15 Q U E S T I O N 4

How should we protect privacy while enabling portability?
20 Q U E S T I O N 5

After people’s data is transferred, who is responsible if thedata is misused or otherwise improperly protected?

24 IV. What’s Next?
25 End Notes

C H A R T I N G A WAY FO R WA R D

2

01

Data Portability
and Privacy

There’s growing agreement among policymakers around theworld that data portability—the principle that you should be
able to take the data you share with one service and move it toanother—can help promote competition online and encourage
the emergence of new services. Competition and data protection
experts agree that, although there are complicated issues
involved, portability helps people control their data and can makeit easier for them to choose among online service providers.
The benefits of data portability to people and markets are clear, which is why ourCEO, Mark Zuckerberg, recently called for laws that guarantee portability.1 But tobuild portability tools people can trust and use effectively, we should develop clear
rules about what kinds of data should be portable and who is responsible forprotecting that data as it moves to different providers.2 The purpose of this paper
is to advance the conversation about what those rules should be.
We hope this paper will anchor a series of conversations among stakeholders
around the globe about how to build portability products in a privacy-protective
way while also helping keep competition vibrant among online services. At theconclusion of the series, we hope to have a portability framework that will improve
our own and others’ product development efforts, guide industry collaborationand potentially inform future legislation.

C H A R T I N G A WAY FO R WA R D

3

01 | Data Portability and Privacy

To that end, the paper sets out five questions about
privacy and portability:
01 What is “data portability”?
Should all user-directed data transfers to third parties be considered“data portability”?
02 Which data should be portable?
Should portable data be limited to only the data a person has provided
to the service provider (and what does it mean to “provide” data)?
03 Whose data should be portable?
If data is associated with more than one person—a common scenario forsocial networking services—should transferring providers limit data
portability? How can providers ensure that each individual’s rights areaccounted for?
04 How should we protect privacy while enabling portability?
What responsibilities, if any, should transferring providers have withrespect to (1) requesting users, (2) others whose interests may be
implicated by a transfer, and (3) potential recipients of the data?
05 After people’s data is transferred, who is responsible if the data ismisused or otherwise improperly protected?
How should responsibility be allocated as between the transferring andrecipient providers? Should users themselves be responsible for issues
that affect their (or their friends’) data?
We’re fortunate to already have perspectives of key stakeholders on thesequestions, such as the EU data protection authorities’ 2017 guidance on the rightto data portability in the context of the European Union’s General Data Protection
Regulation (“GDPR”); two recent papers from Singapore’s Personal Data Protection
Commission; a report on competition policy in the digital era commissioned by theEuropean Commission’s Directorate-General for Competition; and a report on data
mobility commissioned by the UK’s Department for Digital, Culture, Media & Sport.
But we believe the industry would benefit from additional discussion and guidance.
Importantly, this paper focuses on data portability as an action that individual users
of a service choose to take; it does not focus on business-to-business transfers of
information. We recognize that the latter transfers can be important to choice andcompetition, as well. That’s why we’re looking into ways to make data available toother companies that can, for example, help them train artificial intelligence models.

C H A R T I N G A WAY FO R WA R D

4

01 | Data Portability and Privacy

The privacy issues implicated by these kinds of transfers are different from thosethat arise when individuals choose to transfer their data. In this paper, we focus ontransfers initiated by individuals, but we’re continuing to engage with experts as we
look into other types of transfers, as well.
Thank you in advance for participating in this crucial conversation. We welcome
feedback from all stakeholders, and we look forward to hearing your thoughts.

C H A R T I N G A WAY FO R WA R D

5

02

The Challenge

One of our core privacy principles at Facebook is that we enable people to control
the use of their information on our services.3 Guided by that principle, we have built
tools such as the controls that allow people to select the audience for their profile
information and their posts, as well as Ad Preferences, which helps people control
how their information is used to show them ads.
These tools help people control how their information is used on Facebook. But wealso understand that giving people control means facilitating choice and competitionby empowering them to move their information to a different service altogether—that we should, in other words, build products that enable data portability.
Data portability recently became a legal requirement in certain places throughlaws such as the GDPR 4 and the California Consumer Privacy Act (“CCPA”),5 but
Facebook has been considering ways to improve people’s ability to transfer their
Facebook data to other platforms and services for some time. For example, since2010, we’ve offered Download Your Information (“DYI”), which is designed to help
people access and share their information with other online services. In connection
with the GDPR coming into force, we made DYI better suited for portability byenabling people to receive their information in the commonly used structured
JSON format.
Although DYI is a robust data portability tool, we believe we can go further andimprove choice and control by making it even easier for people to export their data
to other services. In his recent op-ed, Mark Zuckerberg wrote that “[t]rue data
portability should look more like the way people use our platform to sign into an app

C H A R T I N G A WAY FO R WA R D

6

02 | The Challenge

than the existing ways you can download an archive of your information.” 6 In otherwords, people should be able to transfer their information directly to a provider of
their choosing, in a way similar to how people use Facebook Login today.
To help achieve this goal, we’ve joined Google, Microsoft, Twitter, Apple, and othersin the Data Transfer Project, an open-source software project designed to help
participants develop interoperable systems that allow individuals to transfer theirdata seamlessly between online service providers.7 This project was inspired in partby the GDPR’s right to portability, but we believe data portability will soon become
the norm in other regions of the world. For example, California’s new data portability
provision will become effective in 2020; governments in Singapore, Australia, India,
Hong Kong, and elsewhere may also soon pass laws supporting portability; and theEuropean Commission is considering portability in the context of competition policy
for the digital age. 8
Proponents of portability recognize that, in order to succeed, industry needs toaddress potential fundamental privacy questions, such as those we pose in thispaper.9 But there has not been detailed guidance with respect to how service
providers could or should balance the benefits to personal autonomy, innovation,and competition from portability against the potential risks to privacy and security.10
For example, the EU’s Article 29 Working Party (succeeded by the European Data
Protection Board, which adopted its guidance) has recognized the risks to security
posed by data portability tools—but has stated only that security measures should
not “obstruct” people from exercising portability rights.11 Similarly, the Working Party
noted the importance of limiting a person’s right to portability where its exercise
could harm other people, but provided no specific guidance on how or when to
implement this limitation.12

C H A R T I N G A WAY FO R WA R D

7

02 | The Challenge

In addition, some guidance on portability seems at odds with other guidance oncompanies’ responsibilities for protecting against data misuse by third parties towhich companies enable data transfers. Privacy regulators have made it clear that,at least in the context of some third-party relationships, platforms like ours shouldhave protections in place that account for the privacy risks that can arise fromtransfers.13 But with respect to the GDPR’s right to portability, the Working Party
both endorses the idea of enabling people to disclose their data to third parties 14
and states that “the data controller is not responsible for compliance of thereceiving data controller with data protection law, considering that it is not thesending data controller that chooses the recipient.” 15
Several reports on competition in digital markets have emphasized the value of
portability for innovation, and have noted that we need to address potential privacy
and security risks. For instance, the report of the UK’s Digital Competition Expert
Panel stated that “[a]ny approach to support this form of data sharing will also haveto ensure that robust privacy safeguards are adopted to respect the privacy rights
and expectations of users.” 16 But the report does not expand on what thosesafeguards should be.
As we move toward a world of greater portability, we and other companies would
benefit from clear rules that help resolve these kinds of questions—questions about
portability, privacy and responsibility.

C H A R T I N G A WAY FO R WA R D

8

03

Five Questions
About Portability
and Responsibility

As discussed above, data portability helps people control their data and choose
the services that best meet their needs. At the same time, portability can present
challenges to safeguarding privacy interests. To address these challenges, we’reseeking feedback and guidance from a wide range of stakeholders about how
to build portability in a way that empowers people and fosters competition while
maintaining their trust in online services.17 In this section, we set out five key
questions, the answers to which will help build the next generation of portability
products. We also offer some thoughts on how to answer these questions to help
further the conversation on these important topics.

QUESTION 1

What is “Data Portability”?
Based on some of the sources that discuss data portability, one might assume thatit’s a straightforward concept with a settled meaning. For example, the Article 29
Working Party explained that, in the GDPR context, portability is simply the right toreceive personal data and transmit it from one service provider to another.18 The
International Organization for Standardization defines “data portability” as the“ability to easily transfer data from one system to another without being required
to re-enter data,” focusing on the ease with which data can be moved.19
But when we move beyond esoteric discussions of portability, we find that there’s
considerable variation in people’s views. In fact, we’ve heard calls—sometimes fromthe same stakeholder—both to enable greater data portability and to limit people’s

C H A R T I N G A WAY FO R WA R D

903 | Five Questions

ability to share their data with third parties.20 The context in which we typically hear
the latter is in connection with our consumer app platform (or “Platform” for short),
which, among other things, refers to the set of technologies we make available fordevelopers that want to enable people to (1) share their Facebook information withthe developer’s app or (2) send information from the developer’s app to Facebook.
The best-known Platform tool is Facebook Login, which enables people to log in
to—and share their information with—third-party apps.
Particularly following the Cambridge Analytica matter, we’ve consistently heard
calls from various stakeholders to limit the information that apps can receive throughFacebook Login and to enhance our oversight of the apps that do receive that
information.21 These calls suggest that some commentators may view the platformto-app transfers of data as different from transfers made possible by “true” data
portability. For example, Facebook’s 2019 Consent Order with the FTC treats
portability transfers separately from other transfers.22
By contrast, other commentators have suggested that Cambridge Analytica
happened because of data portability, implying that platforms like ours (as well as
iOS, Android, Twitter, and others) were already engaging in data portability when
we enabled people to share their data with apps on Platform. 23
The question that comes out of these conversations is: When is a person’s request
to transfer data a portability request? The answer is crucial, not least becauseof the legal rights that attach to portability requests. Under the GDPR, for example,
portability requests must be fulfilled “without hindrance,” raising questions about
whether there are any circumstances in which
a service provider may deny a request, limit thedata available in response to the request, or
restrict the third party’s ability to use the data
following the transfer. It’s clear that many
stakeholders believe platforms should impose
data-use restrictions on recipients of user
data, but the question remains whether service
providers must make alternative mechanisms
available to enable transfers without such
restrictions. If so, how are these two transfers
different from each other?
To begin to answer this question, it is importantto recognize that most user-directed transfersof data to third parties look and operate
similarly. Transfers generally involve threeparties: requesting users, transferring entities,
and recipient entities.24

C H A R T I N G A WAY FO R WA R D

10

03 | Five Questions

From a technical perspective, a data transfer begins when the requesting person
instructs the transferring entity to export his or her data. The transferring entity
then sends the requested data either to the requesting person (who then may use
the data or send it to the recipient entity) or directly to the recipient entity. Oncethe data is shared with the recipient entity, the user can then interact with the dataon or through that service.
But transfers that look similar technically may work differently in practice. One
factor that differentiates transfers is the relationship between the transferring
entity and the recipient entity and the rules, if any, that govern transfers between
them. In general, these user-directed transfers of data to third parties can bethought of as occurring on a spectrum, with progressively more restrictions
imposed as the relationship between the transferring entity and recipient entity
grows closer (setting aside, for the moment, what the scope of the data transferredshould be, which we discuss later in the paper). Three broad categories of userdirected transfers could be described as follows:

1. OPEN TRANSFERS
Requesting users can receive their data and transfer it to any recipient entity
without controls or limitations (beyond those that exist under law) imposed on therecipient by the transferring entity. In this model, either the users can perform thetransfer to a recipient via their own device (as in our DYI tool) or the transferring
entity can facilitate a direct transfer. Apart from the technical connection made forthe purpose of enabling a transfer, there is no relationship between the transferringand recipient entities. This model seems closest to that anticipated by the GDPR
and the Working Party guidance.

Service

B

RequestingUser

C H A R T I N G A WAY FO R WA R D

Transferring
EntityRecipient
Entity11

03 | Five Questions

2. CONDITIONED TRANSFERS
Requesting users can receive their data and transfer it to any recipient that has
met certain conditions imposed by the transferor. The relationship between thetransferring and recipient entities only exists for the purpose of enabling such user
requests; there is no ongoing relationship. As we examine below, this could be a way
to think about user requests to port data directly between services, the technicalmeans for which the Data Transfer Project is working toward.

Open Transfer

Conditioned Transfer

Partnership Transfer

Relationship

3 . PA RTN E RS H I P TR A N S FE RS
Requesting users can receive their data and transfer it to a recipient with which
the transferor has an ongoing relationship regarding such transfers, the terms ofwhich may include provisions on how the recipient may use the data obtained in
the transfer. Here, the relationship between the transferring and recipient entities
exists for a purpose beyond simply effectuating users’ transfer requests—such as,
for example, integrating one of the entities’ features into the other entity’s products.
Transfers through the Facebook Platform are an example of partnership transfers.
When thinking about portability, it helps to acknowledge the differences between
these categories of user-directed data transfers. The question we need to answer
is which transfers should be considered as involving “data portability” and what
obligations on each party in the transaction, if any, should flow from each model?
Open transfers seem to be clearly consistent with the nature of data portability as
described in the GDPR and elsewhere, but what about conditioned transfers, inwhich the transferring entity may choose to limit the third parties to which the user
may send data? Are such limitations consistent with the right to portability? Should
partnership transfers—like the transfers from Platform—ever be viewed as involving
data portability?
In our conversations with stakeholders so far, the general view about thesequestions has been that a transferring entity may—and should—impose someC H A R T I N G A WAY FO R WA R D

12

03 | Five Questions

baseline privacy and data protection restrictions around transfers even whencarrying out the transfer to comply with a portability request. But, as discussed
below, questions remain about what kinds of conditions are appropriate.
Restrictions along the lines of those we impose through Platform strike some as
too restrictive to be consistent with portability. Our recent settlement with the FTC
suggests that some regulators may view Platform-style transfers as distinct fromportability transfers.25 Where the line is between these two categories will likely be
the line between portability and other data transfers.

QUESTION 2

Which Data Should be Portable?
A primary purpose of enabling data portability is to provide individuals with control
over their data. But what exactly is “their data”? It seems clear that people shouldbe able to transfer data such as the photos they upload to a service or the posts
they make to a social network. It’s less clear what other data should be included.
Should people be able to export the information that a service provider receives
as they use its features—information like search history, location data, and activity
logs? What about information generated about people by the service provider on
the basis of people’s uploaded data or their interactions with the service, like theinferences used to personalize music, events, and ads, or to identify potentiallyfraudulent activity?
The GDPR and the Working Party guidance suggest that there should be limits
around the data that is subject to the portability right. The GDPR requires
portability of personal data that a person has “provided to” a data controller.26
The Working Party has suggested that people be able to transfer personal datathat they actively provide to a service provider or that the service provider
observes about them as they use its services, but not data that the service provider
infers about them based on that use. 27
Another question—particularly when it comes to data about a person’s use of aservice—is how service providers’ retention of data might bear on the question ofwhich data should be portable. It seems uncontroversial that service providers
should not be required to retain data solely for the purpose of enabling portability,
so at least some data won’t be portable simply because it won’t be available atthe time of the request. But what about the data that is technically available but
will soon be deleted? Should a service provider build tools to export this data too?
Still another question is whether there are cases in which the burden of making
data portable outweighs the person’s interest in exporting it. For example, aservice’s data about a person’s use of a service could include a list of every pageC H A R T I N G A WAY FO R WA R D

13

03 | Five Questions

or piece of content the person has viewed within a certain period, every link he or she
has clicked on, and every notification he or she has received. Service providers often
keep logs of this information for periods of time, but the process of making
this log data portable could be challenging, and the benefits to the user might notalways be obvious. Would it be useful, for example, to be able to export a list of all
the links you’ve clicked on Facebook within a certain period? Or an archive of every
ad you’ve seen while scrolling through News Feed?
Given that portability is partly intended to encourage competition and the emergenceof new services, we should consider these questions in light of the operational burden
they would impose on service providers with fewer resources than companies like
Facebook. Viewed from that angle, it seems clear that some limitations should be
imposed around a service provider’s obligation to make observed data portable.
Considering data retention periods and weighing the burden on providers against
the benefit to users could be helpful in determining what those limitations should beor to whom they should apply.28 But we will need to answer questions about how any
balancing should be conducted—and by whom.

QUESTION 3

Whose Data Should be Portable?
Providing data portability helps people exercise control over their data. But what
happens when one person wants to transfer data that is associated with anotherperson? What if, for example, Person A wants to move her photos from one service toanother, but those photos include images of Person B? What are Person B’s rights
to control his information in that scenario? What if people want to export the contentsof their phone’s address book or a list of their contacts’ birthdays to a new service?
Should a person’s contacts—whose information would be shared with the newservice—have a say in whether the person may share the information?
As these examples illustrate, it is sometimes difficult to delineate whose data shouldbe transferred in response to a data portability request.29 We’ve found this to beparticularly true for Facebook, a core function of which is to allow users to connect
with other people and create shared experiences. And the ability to transfer data
about your contacts—or friends—can raise especially challenging privacy issues.30
Some have suggested that the only data that should be transferred following
a portability request should be the data that the requesting person “owns.” 31 If therequesting users own the data they provide to a service, the argument goes, thenthey should be able to do whatever they wish with it, including porting it to anotherentity. Conversely, if requesting users do not own some of the data they wish totransfer, then they should not be able to port that data.

C H A R T I N G A WAY FO R WA R D

14

03 | Five Questions

The concept of data as property has been viewed by some as controversial andmay lead to more questions that stretch well beyond the portability context.32 For
example, in practice, many types of information have more than one owner. If you havemy phone number in your address book, for example, are you the owner of that phone
number? Moreover, in the EU, data protection (as a fundamental right) does not varydepending on who, if anyone, “owns” the data in question.33

Another approach to deciding whose data should be madeportable in response to a request could be based on factors suchas who provided the data, whether the service provider has
associated it with a particular user, and the sensitivity of the data.
Consider the following scenario:

Person A uploads a video of herself and three of her friends (Persons B, C, and D).
She doesn’t take any steps that would enable the service to identify her friends(such as “tagging” them). At first glance, it seems clear that Person A should havethe right to port the video to a new service, but what rights, if any, should Persons
B, C, and D have with respect to the video? And who is best positioned (as between
Person A and the service provider) to address those rights?
Now consider a slightly different version of the same scenario: Person A uploads
the video,but this time, she tags Persons B, C, and D, who all happen to be usersof the service. In this scenario, the service provider may be in a position to inform
Persons B, C, and D about a portability request. Assuming this happens, should
they have the right to stop Person A from transferring the video?
How might the answers change if, instead of a video, we were talking about email
addresses in Person A’s contacts list? Should it be easier or harder for Person A
to port them than to port Person A’s photos? What about emails themselves, which
a person might want to export to a new email service (e.g., from Gmail to Outlook)?
We think a multifactor approach that considers questions like these and the factors
above is likely preferable to an approach that focuses on data ownership. But how
we weigh these factors in the analysis of whose data should be portable requires
much more discussion and guidance.34
Commentators often describe the question of whose data should be transferred inconnection with portability as having to do with the portability of a person’s “social
graph”—the map of the connections between a user and other users and entities onthat service. Some advocates of data portability have argued that services like ours
must enable people to transfer their own data as well as data about their social

C H A R T I N G A WAY FO R WA R D

15

03 | Five Questions

graph, in part because the latter data may help enable other social networking
companies to innovate.35 Without a portable social graph, these advocates argue,
users may not be able to seamlessly transfer into alternative social networks.
We think there are strong arguments on both sides: Enabling portability of the social
graph can be important for innovation and competition, but doing so also comeswith important privacy questions. The key question is whether we can find ways toenable this sharing that protect the privacy of all individuals involved. We turnto this issue in the next section.

QUESTION 4

How Should We Protect
Privacy While Enabling Portability?
Questions 1 through 3 involve questions about circumstances before peoplechoose to port their data. Once we know (1) that we’re dealing with a user-directedtransfer of data, (2) which types of data should be transferred, and (3) whose data
should be transferred, we next need to ask how we can enable portability while
protecting privacy.
Although we’re seeing laws that require data transfers—including data portability
laws—there is little guidance around protecting privacy in connection with thosetransfers. Stakeholders have raised concerns about the privacy and security risksof portability tools, and about the lack of clarity from policymakers and regulators
about what is expected of transferring entities.36
More clarity on these points is key because in order for data portability to enhancepeople’s control over their data, users should be able to trust that their data will behandled responsibly during and after the transfer. We’ve found it helpful to think
through these questions about privacy and portability by considering transferring
entities’ actions with respect to (1) requesting users, (2) non-requesting users whose
data would be transferred, and (3) recipient entities.

REQUESTING USERS
Given that portability is about helping people stay in control of their data, it seems
clear that transferring entities should focus on making sure that requesting users
can make informed choices about transferring their data. This means ensuring thatrequesting users have information about the entity to which they want their data to
be transferred. But exactly what kind of information a person should have—and how
it should be made available (and by whom)—are questions that haven’t been fully
answered by policymakers, regulators, or other stakeholders.

C H A R T I N G A WAY FO R WA R D

16

03 | Five Questions

In its assessment of portability under the GDPR, the Working Party explainedthat although people are “responsible” for “identifying the right measures in order
to secure personal data” with the entity to which they’ll transfer their data, thetransferring entity should make the data subject “aware” of measures to enable
the person to take appropriate steps.37
Compare that guidance with a recent discussion paper from Singapore’s Personal
Data Protection Commission, which suggests that transferring entities should go
further, including by providing information such as how user data will be used by thedata recipient; the nature of the new product or service that the user is acquiring;and the track record, reputation, and data management and protection practices ofthe data recipient.38 In its May 2019 consultation paper on the topic, the Commission
further proposed requiring organizations to provide relevant information to people
as part of a binding code of practice.39
These perspectives are helpful starting points, but we think there’s more to discuss
about what, if any, information should be provided to people who want to transfer
their data—as well as how, and by whom, that information could be presented ina helpful way.

NON-REQUESTING USERS
Some data portability requests may involve data associated with people other thanthe person making the portability request (“non-requesting users”). As discussed
above, there are tough questions about whether these users’ data should betransferred at all. If it should, service providers will need to account for the privacy
interests of these users.
Some stakeholders have proposed consent mechanisms or similar means ofallowing people to grant each other permission to have their data exported froma particular service—that is, for User A to be able to grant User B the permission
to share User A’s data with a recipient entity.40 Given the focus on consent as
part of a potential solution to the concern over the porting of non-requestingusers’ data, we want to explore whether—and, if so, how—services could offer
meaningful choice and control to non-requesting users. Would requiring consent
inappropriately restrict portability? If not, how could consent be obtained?
Should, for example, non-requesting users have the ability to choose whether theirdata is exported each time one of their friends wants to share it with an app?
Would such an approach lead to notice fatigue? 41 For users of a particular service,would it be better to give people a setting enabling them to always permit theirfriends (or other contacts) to transfer all—or certain categories—of their personal
data to third parties? And how could we address non-users whose information isshared on a particular service?

C H A R T I N G A WAY FO R WA R D

17

03 | Five Questions

A. Portablility of Social Graph Data
As discussed above, some stakeholders view the transfer of social graphinformation (such as contacts lists) as an important way to help emerging social
networking companies innovate and develop new services.42 There has been
considerable discussion, and some concrete proposals, about ways to enable
the export of this kind of information. Among these proposals, enabling the exportof cryptographically obscured (or “hashed”) versions of users’ and their contacts’unique user identifiers has been described as “[p]erhaps the most promising avenue
for social graph portability.” 43This solution aims to hide user IDs (e.g., email addresses) from the recipient entity
while still providing some ability to reconstruct the transferring users’ social graph,potentially helping address the privacy challenges of sharing friends’ data withthird parties by avoiding unnecessary exposure of personal data. However, experts
have noted that this proposal would “require a major collaborative technical effort
that could raise unanticipated privacy and security challenges as well as legal
compliance questions[.]”44 Below, we explore two commonly discussed approaches
to sharing hashed contacts’ data and the potential challenges such approaches
could raise.
First, a provider could share a list of hashed identifiers that are associated with therequesting user and their contacts. The simplest way of doing this is to share hashedversions of a contact’s name (which is not necessarily unique) or email address. If
Users A and B are both connected to User C, and both share their hashed contacts’lists with a service, then that service will know that User A and User B are bothconnected to User C, but it cannot learn additional information about User C unlessUser C has also ported his or her personal data to the same service.
Another option is to share identifiers not associated with users but rather withrelationships between users. In this system, if Users A and B are both friends with
User C, and both share their contacts lists, then—unlike above—the recipient
service cannot know that Users A and B are both friends with User C. This isbecause the identifier for the relationship between Users A and C is different fromthe identifier for the relationship between Users B and C. However, if User C chooses
to also share their contacts list, then User C will share the same two identifiers fortheir relationship with Users A and B respectively, at which point the receiving
service can match up these identifiers to know that User C is connected to User A
and User B.
Both of these approaches have drawbacks that require further discussion withstakeholders. In the first approach, it may be possible for the recipient to infer
information about User C based solely on their relationship with Users A and B. For
example, if Users A and B share an employer or are members of the same politicalparty, then the recipient may be able to infer those facts about User C andC H A R T I N G A WAY FO R WA R D

18

03 | Five Questions

determine User C’s identity with minimal additional information. The second
approach doesn’t suffer from this issue, but its utility to the recipient may be more
limited because a relationship is only recognizable by the recipient service if bothcontacts choose to share their information with the recipient service.
Another challenge for social graph sharing is to settle upon a common data modelthat is specific enough to be useful but broad enough to apply across services. For
example, some social networks have a single account per user, while others allow
multiple accounts for one user. If User A is connected with one of User B’s accounts
but not with another, how should this relationship be reflected when either user
shares a contacts list with a service that permits only a single account per user?
Further risk of data leakage is introduced when users who port contacts data froma pseudonymous social network to one that requires real names. Recipients (or eventhe requesting user) may be able to infer the actual identities of pseudonymous
users based on commonalities with their known contacts.
Moreover, social graph sharing can grow more complex as we consider additional
layers of social interaction. For example, if one of User A’s posts is ported toanother social network and User B has commented on or liked that post, whenshould that comment be visible, who should be able to see it, and how should
User B be identified, if at all, on the new service? The answers to those questions
could vary based not only on the audience controls at the new service, but also
on the mechanism used to port and identify contacts at the new service.

P O T E N T I A L R E C I P I E N T S O F P E R S O N A L D ATA
Over the past year, we have heard calls from many stakeholders that service
providers should make additional efforts to protect against data misuse byat least certain third parties.45 But what should those efforts consist of when it
comes to portability?
There is little expert commentary on this question. In the GDPR context, theWorking Party’s guidelines state only that a transferring data controller “isresponsible for taking all the security measures needed to ensure . . . that personal
data is securely transmitted (by the use of end-to-end or data encryption) to theright destination (by the use of strong authentication measures).” 46 The guidelines
suggest risk mitigation measures, such as using additional authentication
information, or suspending or freezing transmission if there is suspicion that an
account has been compromised. However, these security measures “must not be
obstructive in nature and must not prevent users from exercising their rights[.]” 47
Apart from these basic steps, the Working Party does not offer guidance on how
service providers should protect against misuse by third parties. In conversations
with stakeholders, we often hear that transferring service providers should consider

C H A R T I N G A WAY FO R WA R D

19

03 | Five Questions

imposing additional controls to ensure that recipients process user data withprivacy and security in mind. For instance, providers could require recipients tocertify (1) the purposes and uses for the personal data they may receive pursuant toa data portability request, and (2) that they are processing data in accordance withapplicable laws and data protection requirements. We also hear that providers
should even consider monitoring recipient entities’ processing of data and enforcing
against recipient organizations who fail to process data according to applicablelaws and data protection requirements, an extremely challenging (if not impossible)
requirement and one that seems not to be required under the GDPR formulationof portability.
At the same time, we hear concerns that these kinds of requirements may be
inconsistent with “true” portability: If people want to transfer their data toa particular entity, what business is it of the transferring entity to assess the
purposes for which the person’s data will be processed or whether the recipientcomplies with the law? What if the transferring entity and the recipient disagree
about what the law requires? Should the transferring entity get to decide? Theremay be a point at which the transferring entity’s efforts to exercise diligencebeyond securing the transfer may impose undue friction on the abilities of users
to switch to competing services.
One proposed response to such concerns is an accreditation system.48 Underan accreditation model, potential recipients of user data could demonstrate,
through certification to an independent body, that they meet the data protection
and processing standards found in a particular regulation, such as the GDPR.49
Accredited entities could then be identified with a seal and would be eligible toreceive data from transferring service providers. The independent body (potentiallyin consultation with relevant regulators) could work to assess compliance ofcertifying entities, revoking accreditation where appropriate.
Another potential solution, which may be compelling to providers that operate ina country without a comprehensive data protection framework, could be thecreation of a portability-focused code of conduct administered by an independent
organization.50 The code of conduct could require entities to implement privacy
and security safeguards before receiving user-requested data. The independent
organization could engage in monitoring and enforcement of its signatories forpotential violations. A key question for this model would be how it should treat
recipient entities that fail to comply with or don’t sign on to the code. Even if theuser’s request to transfer information to such a recipient must be fulfilled,
information about a recipient’s noncompliance with (or refusal to sign on to) thecode of conduct may still provide important information to users about the entity’s
privacy and security safeguards.

C H A R T I N G A WAY FO R WA R D

20

03 | Five Questions

QUESTION 5

After people’s data is transferred, who is
responsible if the data is misused or otherwise
improperly protected?
People and service providers need clarity on who is responsible for processing
and protecting data before, during, and after a user-requested data transfer.
Regulators have taken the position that platforms like Facebook may be responsible
for ensuring that data is protected following certain user-requested transfers ofdata to third parties. Is that the case when it comes to data portability requests?
With respect to the exercise of the GDPR’s portability right, the Working Party’s
guidelines provide a clear allocation of responsibility when a service provider
ports data to another entity at a user’s request. 51 Responsibility and liability
generally follow user data to its new destination. Before and during any datatransfer, the transferring service provider is responsible for ensuring that they act
on the requesting user’s behalf, securing the transmission on its way to the correct
recipient, and mitigating any risks associated with data portability. Recipients
must ensure that they receive only data that is necessary and relevant to theservice they are providing to the requesting user.
After the transfer, the transferring service provider is not responsible for theprocessing handled by the data subject or by another company receiving personal
data (since they are only acting on behalf of the data subject and not choosing therecipient organization). Instead, according to the Working Party, responsibility vests
in the recipient, which must now process and protect the personal data it accepts
according to its obligations under the GDPR.
The Personal Data Protection Commission of Singapore’s discussion paper also
proposes a liability model, in which transferring entities would be exempted fromclaims for damage arising from misuse of data by the recipient—a result theCommission believes appropriate, given that transferors cannot feasibly vet all
potential recipients. The paper also states that the transferor should not be liablefor claims “relating to the accuracy and quality of the ported data unless it wasdemonstrated that the data was corrupted while under the care of the[transferor].” 52 In its most recent consultation paper on the topic, the Commission
does not mention liability but appears to limit post-transfer responsibilities fortransferor entities to “check[ing] that the data transmitted has been received
by the receiving organization and assist[ing] with any queries it may have withrespect to the data transmitted.” 53
But there are clearly some circumstances in which policymakers and regulators
expect transferring entities to maintain responsibility even after the transfer. OneC H A R T I N G A WAY FO R WA R D

21

03 | Five Questions

way to harmonize this reality with the Working Party’s guidelines and the Personal
Data Protection Commission’s discussion paper may be to further clarify that
service provider responsibility may vary depending on where on the spectrum atransfer falls—i.e., whether it is an open transfer, a conditioned transfer, or apartnership transfer, as discussed in Section II.A. For instance, should providers be
deemed more accountable in a partnership transfer (e.g., a model like Facebook’s
Platform) due to the closer nature of their relationship with the recipientorganization and a purpose for the transfer that extends beyond satisfying arequest from a user?
For open transfers, perhaps the most a service provider should be responsible foris helping users take responsibility for the risks associated with taking their data to
a new service; provided this has occurred, responsibility for protecting data would
rest solely with the recipient. Service providers might explore tools to help users
understand security risks and protocols for their downloaded data. Providers could
also consider giving users guidance on how to inspect recipient organizations forpotential abuse or insufficient security safeguards. For instance, providers could
teach users ways to confirm the authenticity of the recipient organization (that it iswhat it says it is); check the website security for recipient organizations (e.g., thedifference between HTTP and HTTPS); secure their devices when they download
data (e.g., not using public Wi-Fi when downloading data); and identify whether therecipient organization has appropriate policies in place (e.g., checking privacy
policies to determine whether an entity will sell user data that it receives).
For conditioned transfers, one approach would be for service providers to require
recipients to certify that they’re accredited by a standards body, in compliance witha relevant code of conduct, or otherwise that they will process personal data inaccordance with applicable laws and data protection requirements before fulfillinga transfer request. Once providers have received such a certification, they could
be relieved of responsibility (and liability) for data issues that arise after transfer.
For partnership transfers, it may be more appropriate to impose some degreeof responsibility on the transferring entity, even for conduct that occurs after thetransfer. To the extent feasible, some enhanced oversight of recipients’ handlingof people’s data following a transfer may also be appropriate.
Finally, there is the complex question of responsibility when it comes to individuals
about whom data is transferred by another party as part of a portability request.
The Working Party guidelines note that if a user’s data portability request involves
personal data belonging to third parties, the requesting user is also responsible forthe processing operations that the user initiated (to the extent that such processing
is not decided by the controller), outside of an exemption for household or personal
use.54 Imposing responsibility (and liability) for requesting users who transfer
contacts’ data could chill interest in portability generally, and in social graph

C H A R T I N G A WAY FO R WA R D

22

03 | Five Questions

portability specifically. Could a better outcome be to limit liability for requestingusers to only cases involving truly unreasonable or reckless behavior, such as
knowingly transferring their contacts’ data to a party known to have a history ofdata misuse or poor data protection practices?

C H A R T I N G A WAY FO R WA R D

23

04

What’s Next?

Data portability promises to give people unprecedented control of their informationand to support continued vibrant innovation and competition online. The GDPR
and other laws have prompted considerable investment in portability tools. This
paper and the conversations that will follow it are intended to promote portability
by laying out the issues and starting to address hard questions about how
portability can be implemented in a privacy-protective way. We strongly believethat it can, and we look forward to collaborating with a range of stakeholders on
solutions in the months to come.

C H A R T I N G A WAY FO R WA R D

24

END NOTES

Data Portability and Privacy:
Charting a Way Forward1.

	 See Mark Zuckerberg, The Internet Needs New Rules. Let’s Start
in These Four Areas, Wash . Post (March 30, 2019), https://www.
washingtonpost.com/opinions/mark-zuckerberg-the-internetneeds-new-rules-lets-start-in-these-fourareas/2019/03/29/9e6f0504-521a-11e9-a3f7-78b7525a8d5f_
story.html?utm_term=.6247ef86cd32.

(Oct. 24, 2018), https://ico.org.uk/media/action-weve-taken/
mpns/2260051/r-facebook-mpn-20181024.pdf; O ffice of thePrivacy Commissioner of Canada , PIPEDA Report of Findings#2019-002 (Apr. 25, 2019), https://www.priv.gc.ca/en/opcactions-and-decisions/investigations/investigations-intobusinesses/2019/pipeda-2019-002/; Stipulated Order for Civil
Penalty, Monetary Judgment, and Injunctive Relief, UnitedStates v. Facebook, Inc., No. 19-cv-2184 (F.T.C. July 24, 2019),
https://www.ftc.gov/system/files/documents/cases/182_3109_
facebook_order_filed_7-24-19.pdf [hereinafter Facebook
Decision and Order].

2.

	 See id.

3.

	Facebook Privacy Principles, Facebook , https://www.facebook.
com/about/basics/privacy-principles (last visited Aug. 16, 2019).

4.

Regulation 2016/679 of the European Parliament and of theCouncil of 27 April 2016 on the Protection of Natural Persons
with Regard to the Processing of Personal Data and on the Free
Movement of Such Data, and repealing Directive 95/46/EC, 2016
O.J. L 119/1, art. 20 [hereinafter GDPR].

14.

5.

	Cal. Civ. Code § 1798.100(d) (effective Jan. 1, 2020).

6.

	Zuckerberg, supra note 1.

7.

	See About Us, Data Transfer Project, https://datatransferproject.
dev/ (last visited Aug. 16, 2019).

8.

	 See Jacques Crémer, et al., Competition Policy for the Digital Era,
Report for the European Commission (2019), http://ec.europa.
eu/competition/publications/reports/kd0419345enn.pdf.

9.

	 See Jason Furman et al., Unlocking Digital Competition, Report of
the Digital Competition Expert Panel 9 (2019), https://assets.
publishing.service.gov.uk/government/uploads/system/
uploads/attachment_data/file/785547/unlocking_digital_
competition_furman_review_web.pdf (“There may be situations
where opening up some of the data held by digital businesses
and providing access on reasonable terms is the essential andjustified step needed to unlock competition. Any remedy of thiskind would need to protect personal privacy and consider
carefully whether the benefits justified the impact on thebusiness holding the data”).

	 See Art. 29 Working Party, Guidelines, supra note 11, at 19.

15.

See id. at 6 (emphasis added).

16.

	Furman et al., supra note 9, at 80.

17.

	 These challenges go beyond the traditional data security
challenges that arise in making personal data accessible
through technical means (although those challenges are, in andof themselves, quite substantial). The risk of inadvertent
disclosure or data leakage inevitably grows as the ways toaccess systems increase. The complex, independent systems
that are needed to implement data portability will necessarily
create additional ways to access data and controlled services—which may translate to greater security risks to users. See
generally John Palfrey & Urs Gasser , B orn D igital: Understanding theFirst G eneration of D igital Natives (2011).

18.

	 See Art. 29 Working Party, Guidelines, supra note 11, at 5.

19.

	I nternational O rganization for Standardisation , ISO/IEC 19941:2017,
Information Technology – Cloud Computing – Interoperability andPortability (2017), https://www.iso.org/obp/ui/#iso:std:66639:en.

20.

See Facebook Decision and Order, supra note 13. But see
Separate Statement of Commissioner Noah Joshua Phillips,
Federal Trade Commission v. Unrollme Inc., No. 1723139 (Aug. 8,2019), https://www.ftc.gov/system/files/documents/public_
statements/1539865/phillips_-_unrollme_statement_8-8-19.pdf(suggesting that Google’s restriction of third parties from using
the information in the Gmail accounts of consumers for purposessuch as market research or advertising, while promoted as ameans to enhance consumer privacy, may also limit consumer
choice and competition).

10.

	 See, e.g., Datum Future, Data Portability: What is at stake? (July
2019), https://www.datumfuture.org/wp-content/
uploads/2019/07/Datum-Future-Data-Portability-July-2019.pdf.

11.

	 See Article 29 Data Protection Working Party, Guidelines on the
Right to Data Portability, at 19 (2017), http://ec.europa.eu/
newsroom/document.cfm?doc_id=44099 [hereinafter Art. 29
Working Party, Guidelines].

12.

	 Id. at 11.

21.

	 See sources cited supra note 13.

13.

	 See, e.g., I nformation Commissioner’s O ffice, M onetary Penalty N otice22.

	Facebook Decision and Order, supra note 13.

C H A R T I N G A WAY FO R WA R D

25

END NOTES

23.

	See, e.g., Ben Thompson, The Bill Gates Line Follow-up, Twitterand the Bill Gates Line, Data Portability and Facebook,
Stratechery (May 29, 2018), https://stratechery.com/2018/the-bill-gates-line-follow-up-twitter-and-the-bill-gates-linedata-portability-and-facebook/ (acknowledging that “forced
data portability and interoperability” would “return[] Facebook
to the state it was with the original social graph API,” which iswhat prompted Cambridge Analytica); Ben Thompson, The
Facebook Brand, Stratechery (Mar. 19, 2018), https://stratechery.
com/2018/the-facebook-brand/ (noting that Facebook Graph
API allowed users to “give away everything about their friends”
and “this is exactly how the researcher implicated in the
Cambridge Analytica story” gained access to Facebook userdata); Paul Przemysław Polański, Some Thoughts on Data
Portability in the Aftermath of the Cambridge Analytica Scandal,
7 J. of Eur . Consumer and Market L. 141 (2018) (describing
Cambridge Analytica as the result of flawed API implementationand calling for a conservative construction of the data
portability right).

24.

There are various technical means for accomplishing thesetransfers, and researchers are currently developing multilateral models that allow individuals to manage their data anddecide where to store it. For example, personal information
management systems (“PIMS”) let individuals store their data
either locally or via cloud-based storage and let them “define ata sufficiently granular level how their personal information
should be used and for what purposes.” See Eur. Data Protection
Supervisor, EDPS Opinion on Personal Information Management
Systems, Opinion 9/2016, at 7 (Oct. 20, 2016), https://edps.
europa.eu/sites/edp/files/publication/16-10-20_pims_opinion_
en.pdf. In addition, an MIT project, “Solid,” aims to create“decentralized social applications” that will allow individuals tomove their information wherever they choose and switch
between multiple platforms. See CSAIL-MIL, What Does Solid
Offer?, Solid , https://solid.mit.edu/ (last visited May 22, 2019).
The Data Mobility Infrastructure Sandbox began evaluating theviability of data portability facilitated by entities like PIMS
earlier this year. See Ctrl-Shift, Data Mobility Infrastructure
Sandbox (2019), https://www.ctrl-shift.co.uk/wp-content/
uploads/2019/06/DMIS_June_2019_Downloadable_Singles_
Final4.pdf.

25.

Hawley Introduce Bill to Force Social Media Companies toDisclose How They Are Monetizing User Data (June 24, 2019),
https://www.warner.senate.gov/public/index.cfm/2019/6/
warner-hawley-introduce-bill-to-force-social-mediacompanies-to-disclose-how-they-are-monetizing-user-data.
As another example, in a recent hearing Rep. Jan Schakowsky(D-Ill.) noted that “[w]e must not lose sight of small andmedium-sized businesses and how heavy-handed laws andregulations can hurt them. Established bigger companies cannavigate a complex and burdensome privacy regime. But
millions of dollars in compliance costs aren’t doable for startups
and small businesses.” See Protecting Consumer Privacy in the
Era of Big Data: Hearing Before the Subcomm. on Consumer Prot.
of the Comm. on Energy & Commerce, 116th Cong. (2019)(statement of Rep. Jan Schakowsky, Subcomm. Chair). Similarly,
EU policymakers have sought to avoid disproportionate burdens
on small- and medium-sized enterprises by legislating exceptions
to certain data protection obligations. See, e.g., GDPR, art. 30(5)(exempting SMEs with 250 or fewer employees from certain
GDPR record-keeping obligations). The GDPR also seeks tominimize disproportionate burdens on providers by permitting
controllers to refuse to comply with data subject rights where
requests are “manifestly unfounded or excessive, in particular
because of their repetitive character.” See GDPR, art. 12(5)(b).
29.

See, e.g., Dr. Aysem Diker Vanberg, The Right to Data Portability
in the GDPR: What Lessons Can Be Learned from the EU
Experience, 21(7) J. Internet L. 1, 3 (2018) (“[A]llowing one user totransfer a second user’s information to another platform may
violate the privacy rights of a second user.”); Helena Ursic,
Unfolding the New-Born Right to Data Portability: Four Gateways
to Data Subject Control, 15(1) SCRIPT- ed 42, 56 (2018), https://
script-ed.org/wp-content/uploads/2018/08/ursic.pdf (noting“additional difficulties in applying the right to data portability”
when data contains “multiple persons’ data which are . . .
intertwined”); Barbara Engels, Data Portability Among Online
Platforms, 5 I nternet Pol’y Rev., June 2016, 4-5, https://policyreview.info/articles/analysis/data-portability-amongonline-platforms (“Allowing one to transfer a second user’s
information may violate the privacy rights of second user.”).

30.

See Comments of New America’s Open Technology Institute, In re
Competition and Consumer Protection in The 21st Century: The
Intersection Between Privacy, Big Data, and Competition, at 4
(F.T.C. Aug 20, 2018), https://www.ftc.gov/system/files/
documents/public_comments/2018/08/ftc-20180051-d-0034-154926.pdf [hereinafter OTI Comments] (“[N]owhere is [the tension between the right to portability andfriends’ right of privacy] greater than when it comes to theportability of information about your contacts on social
networks, or your ‘social graph.’”).

31.

	 See, e.g., Ira Rubinstein, Big Data: The End of Privacy or a New
Beginning?, 3 I nt’l Data PrivacyL. 74, 74–87 (2013), (supporting theidea of a property-based model of personal data that protects
privacy); Paul M. Schwartz, Property, Privacy, and Personal Data,
117 Harv. L. Rev. 2056 (2003), https://scholarship.law.berkeley.
edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=
1068&context=facpubs (developing a model of propertized
personal information that protects privacy); see also Peter Swire& Yianni Lagos, Why the Right to Data Portability Likely Reduces
Consumer Welfare: Antitrust and Privacy Critique, 72 M d . L. Rev.
335, 373 (2013) (suggesting that right to data portabilityT hird parties who receive Covered Information through “aUser-initiated transfer of Covered Information as part of a data
portability protocol or standard” are not necessarily subject tothe same controls and safeguards as third parties who receive
Covered Information through other means. See Facebook
Decision and Order, supra note 13.

26.

G DPR, art. 20(1).

27.

	 See Art. 29 Working Party, Guidelines, supra note 11, at 9.

28.

The importance of ensuring that new requirements do not
overburden smaller companies is a theme that has beensounded by many U.S. policymakers crafting privacy legislation.
Several privacy bills contain certain exceptions for small entities.
The DASHBOARD Act put forth by Sens. Mark Warner (D-VA)
and Josh Hawley (R-MO), for example, limits its applicability toentities that “(1) generate a material amount of revenue from theuse, collection, processing, sale, or sharing of the user data; and(2) have more than 100,000,000 unique monthly users in the
United States for a majority of months during the previous 1-year
period.” See Press Release, Sen. Mark R. Warner, Warner &C H A R T I N G A WAY FO R WA R D

26

END NOTES“appears more closely akin to the personal data ownershiptheory” than the right of access, and acknowledging debate
around whether personal information is property).
32.

33.

34.

35.

36.

37.

See, e.g., Hayley Tsukayama, Knowing the “Value” of Our Data
Won’t Fix Our Privacy Problems, Electronic Frontier Foundation(July 15, 2019), https://www.eff.org/deeplinks/2019/07/
knowing-value-our-data-wont-fix-our-privacy-problems; Sarah
Jeong, Selling Your Private Information Is a Terrible Idea, N.Y.
Times (July 5, 2019), https://www.nytimes.com/2019/07/05/
opinion/health-data-property-privacy.html.
See Eur. Commission, Staff Working Document on the Free Flowof Data and Emerging Issues of the European Data Economy(Jan. 10, 2017), https://ec.europa.eu/digital-single-market/en/
news/staff-working-document-free-flow-data-and-emergingissues-european-data-economy; see also Cameron F. Kerry &John B. Morris, Why Data Ownership Is the Wrong Approach toProtecting Privacy, B rookings I nstitution (June 26, 2019), https://www.brookings.edu/blog/techtank/2019/06/26/why-dataownership-is-the-wrong-approach-to-protecting-privacy/.
S imilar considerations could apply when determining how toaddress privacy issues in connection with business-to-business
transfers of data (which, as noted above, are beyond the scopeof this paper, but just as important to enabling competition as
the individual right to data portability). In the context of thesetransfers, there are often additional factors present that cangreatly impact the privacy issues around the transfer.
See Bennett Cyphers & Danny O’Brien, Facing Facebook: Data
Portability and Interoperability Are Anti-Monopoly Medicine,Electronic Frontier Foundation(July 24, 2018), https://www.eff.org/
deeplinks/2018/07/facing-facebook-data-portability-andinteroperability-are-anti-monopoly-medicine; Kevin Bankston,
How We Can ‘Free’ Our Facebook Friends, N ew America Weekly(June 28, 2018), https://www.newamerica.org/weekly/
edition-211/how-we-can-free-our-facebook-friends; see also
Orla Lynskey, Aligning Data Protection Rights with Competition
Law Remedies? The GDPR Right to Data Portability, Eur . L. Rev.
793, 804-05 (2017) (“[T]he inability to access [“friends” data]
could constitute a barrier to entry for potential competitors.”).
But see Thompson, The Bill Gates Line Follow-up, supra note 23.
S ee, e.g., OTI Comments, supra note 30, at 4 (“Most services will
now let you download your own social media posts, but what
about other people’s comments to those posts, or yourcomments and tags on other people’s posts and photos? . . . .
These are just some of the examples of the unresolved tension
between my right to portability and my friends’ right to privacy,
and nowhere is that tension greater than when it comes to theportability of information about your contacts on social
networks, or your ‘social graph.’”); Lynskey, supra note 35, at 808(“A further potential cost and complication for data controllers
will be ensuring data security, given the tension between data
security and data access. The A29WP perhaps underestimatesthe extent of this challenge for data controllers stating simply
that the GDPR right may also ‘raise some security issues’ while
highlighting that the data controller will remain responsible for‘taking all the security measures needed to ensure that personal
data is securely transmitted[.]’”); Vanberg, supra note 29, at 7(“The Article 29 Working Party arguably has not succeeded inoffering more clarity as to what security standards are
expected.”).
	 See Art. 29 Working Party, Guidelines, supra note 11, at 19.

C H A R T I N G A WAY FO R WA R D

38.

S ee Personal Data Protection Commission of Singapore, D iscussion
Paper on Data Portability 20 (Feb. 25, 2019), https://www.pdpc.
gov.sg/-/media/Files/PDPC/PDF-Files/Resource-forOrganisation/Data-Portability/PDPC-CCCS-Data-PortabilityDiscussion-Paper---250219.pdf [hereinafter PDPC D iscussion
Paper].

39.

See Personal Data Protection Commission of Singapore, Public
Consultation on Review of the Personal Data Protection Act of 2012
− Proposed Data Portability and Data I nnovation Provisions 17 (May22, 2019) [hereinafter PDPC Public Consultation].

40.

See Gennie Gebhart, Bennet Cyphers & Kurt Opsahl, What We
Mean When We Say “Data Portability,” Electronic Frontier
Foundation (Sept. 13, 2018), https://www.eff.org/
deeplinks/2018/09/what-we-mean-when-we-say-dataportability; Bankston, supra note 35.

41.

	 Notification fatigue is a problem often discussed in the breach
notification context. See, e.g., Jeri Clausing, ‘Security Fatigue’
Complicates the Battle Against Data Breaches, I nternet Soc’y(Dec. 21, 2016), https://www.internetsociety.org/blog/2016/12/
security-fatigue-complicates-the-battle-against-databreaches/; Christopher Mele, Data Breaches Keep Happening.
So Why Don’t You Do Something?, N.Y. Times (Aug. 1, 2018), https://www.nytimes.com/2018/08/01/technology/data-breaches.html.

42.

See Bankston, supra note 35; Josh Constine, Facebook Shouldn’t
Block You from Finding Friends on Competitors, Tech Crunch (Apr.
13, 2018), https://techcrunch.com/2018/04/13/free-the-socialgraph; Cyphers & O’Brien, supra note 35; see also Lynskey, supranote 35, at 804-05 (“[T]he inability to access [“friends” data]
could constitute a barrier to entry for potential competitors.”).
But see Thompson, The Bill Gates Line Follow-up, supra note 23.

43.

See OTI Comments, supra note 30, at 6-7.

44.

	Id. at 7.

45.

	See, e.g., sources cited supra note 13.

46.

A rt. 29 Working Party, Guidelines, supra note 11, at 19.

47.

Id.

48.

See PDPC D iscussion Paper , supra note 38, at 20; Gus Rossi &Charlotte Slaiman, Interoperability = Privacy + Competition,
Public Knowledge (Apr. 26, 2019), https://www.publicknowledge.
org/news-blog/blogs/interoperability-privacy-competition(“[B]ecause they are dealing with personal data, third parties
that want to interoperate would be required to follow a clear
and transparent open model for user privacy, including potential
requirements for pre-approval or certification by anindependent entity.”).

49.

S ee, e.g., GDPR, art. 42-43.

50.

The Personal Data Protection Commission of Singapore recently
proposed that it be given the power to issue binding codes ofpractice for sectors related to consumer safeguards,
counterparty assurance, interoperability, and security of data.
See PDPC Public Consultation , supra note 39, at 17 (the codes ofpractice would provide minimum standards for interoperability
and security, criteria to verify the identity of recipientorganizations prior to transfer, and information that must be
provided to consumers to enable them to exercise their right todata portability).

51.

	 See Art. 29 Working Party, Guidelines, supra note 11, at 6-7.

52.

See D iscussion Paper , supra note 38, at 20.

53.

See PDPC Public Consultation , supra note 39, at 14.

54.

A rt. 29 Working Party, Guidelines, supra note 11, at 11.

27