SEKE 2012 Proceedings - Knowledge Systems Institute

oader permissions than what are legitimately necessary
for their services. Not mindful of the privacy implications,
many users grant these permissions, bypassing this layer of
protection as well. Thus, despite the mechanisms available
to limit the exposure of information, OSN APIs can easily
compromise users’ privacy.
This paper presents a comparative analysis of the propensity
of OSN APIs to violate user privacy. Ever since Facebook
CEO Mark Zuckerberg famously defended the change
to make user activity public-by-default, technologists have
asserted that the “Age of Privacy” on the Web is over. 1 We
seek to verify the truth in this assertion by examining the
APIs of six popular and widely used OSNs. We f nd substantial
support for this assertion because OSNs: (i) facilitate a
collection of detailed user data; (ii) provide limited privacy
settings and control; and (iii) use ambiguous requests to seek
unnecessarily broad and general permissions.
The paper is organized as follows: Section 2 introduces
OSN APIs and privacy control mechanisms. Section 3
presents our comparative analysis. Section 4 summarizes
our f ndings and offers directions for future work.
2 OSN APIs: An Overview
Fundamentally, OSNs offer a platform for users to connect,
interact, and share information. Each user is represented
with a prof le that contains the user’s information.
A social feed attached to the prof le provides a forum to
share information. OSN users establish connections; and
updates to their social feeds are broadcast to their connections.
Popular OSNs differ with respect to what constitutes
user connections and the information shared via social feeds.
User connections on Facebook, Orkut, and Google+ are bidirectional
friendships, social feeds include status updates,
photos, videos and posts by other users, and updates can be
broadcast to all or a subset of users’ connections. Twitter
(YouTube) def nes uni-directional relationships where users
subscribe to receive other users’ updates (video uploads).
Each OSN designs an API to allow third parties to collect
information or to act on behalf of their users. These open,
Web-based APIs can be queried with HTTP requests to retrieve
a particular user’s information. For example, the request
https://graph.facebook.com/220439 retrieves
all the public information on Facebook’s CTO. A
request to http://search.twitter.com/search.
json?q=happy returns recent tweets which include the
word happy. Frequently, the APIs also return irrelevant information;
for instance, the above Twitter call returns the
name, user id, and a link to the user’s photo for each tweet.
OSN users may expect that their shared information will
be protected at the friendship, network, and public levels
[6]. Friendship- and network-level protection prevents
unintended disclosure, and users believe that these may be
achieved through privacy settings. They may also presume
1 http://news.cnet.com/8301-17852 3-10431741-71.html
Figure 1. API access and privacy protection
public-level protection, because their notion of an OSN is a
walled garden, impenetrable without authorization. Piercing
through these privacy expectations, however, are the open
access APIs. Most OSNs thus try to restore users’ perception
of privacy by empowering them with two forms of control:
(i) conf gurable privacy settings; and (ii) express permission
requests from third parties.
Understanding how the APIs of six popular OSNs balance
these competing concerns of information access versus
user privacy is the focus of this paper. We choose these
OSNs because of their extreme popularity, widely varying
purposes, and unique features as summarized in Table 1. We
measure popularity in terms of the number of users 2 and include
representative (not exhaustive) prof le data.
3 Comparative Analysis
We extensively analyzed the online documentation, and
aggregated the details of each OSN API along three dimensions:
(i) user information that can be collected; (ii) privacy
settings that can be conf gured; and (iii) permissions that
may be requested. 3 For each dimension, we def ne the coverage
metric as the percentage of the number of features that
the API currently implements to the total number of features
that it can feasibly provide, given the context and the functionality
of the site. Because the total number of feasible
features is determined by the union of the features across
all APIs, it is inherently subject to our interpretation of the
APIs. Therefore, we intend to use the coverage metric as a
2 http://vincos.it/social-media-statistics
http://royal.pingdom.com/2011/02/04/facebook-youtube-our-collectivetime-sinks-stats
3 API details are available at http://www.cse.uconn.edu/∼ded02007/osnapi.
401