WIXLIB

categories are business, education, entertainment, friends &family, games, just for fun, lifestyle, sports, and utilities. Wecollected data from the top 200 most popular applications fromeach category. By going through the list of these applications, werecorded the profile page URL for each application. Then, weused the software “Locoyspider” to collect and save data fromthese profile pages, as well as record the number of monthlyactive users for these applications. Next, we used the list of “Go toApp” URLs to either access the authentication dialog (“Requestfor Permission”) which lists all the information that the apprequests from users, or to be redirected to the app’s external page.In our dataset, we only consider those applications which wouldpop-up the privacy authentication dialog after clicking the buttonof “Go to App”. From these authentication dialogs, we capture thetypes of information each app desires to access from users.Combining this information (i.e., types of information requests)with the number of monthly active users for each application, wecan count how many times a specific type of information isreleased to an app within a month.Figure 3. Current Third-Party Apps’ Authentication Dialog asof 5/10/2011.2.2.2 Information Control after Installing AppsIn the Facebook privacy settings, there is a section called “Appsand Websites” which enables users to control certain aspects ofthe information sharing between them and previously installedapps. As shown in Figure 4, users could remove someinformation categories from this list, which would make that typeof information no longer available to the app. There are, however,four categories of information that cannot be removed (i.e., “Sendme email”, “Access my profile information”, “Access my friends’information”, and “Access my photos and videos”).Among those 1800 most popular applications, there were 1305applications displaying authentication dialogs when theyrequested data access from users. From the end user’s perspective,there were 12 categories of information/behavior requested by theauthentication dialogs. For each category of these requests, wefirst compiled a list of applications that require it. We summed upthe number of monthly active users for each application on the listto get the total number of users who were requested for this typeof information. We treat this total number as the total times thatsuch user information is requested per month (see Table 1).Table 1. Authorization Requests Presented to the User.Data Category/Access Category3. THIRD-PARTY APPS’ DATACOLLECTION PRACTICESIn this section, we discuss the scope of user information that appscould potentially collect from users of the Facebook platform andtransmit to advertising companies or other third parties. Field datafrom the most popular 1800 third-party apps on Facebook wascollected in December 2010 and analyzed to investigate thirdparty apps’ data collection practices.From the Facebook application directory2, we locate the URLs forthe most popular 1800 applications in nine categories. These nine2See URL: otal times acategory isrequested by appsAccess my basicinformationSend me email1305 (100%)857,821,274454 (34.79%)238,991,048Post to my wall670 (51.34%)137,473,280148 (11.34%)178,912,31676 (5.82%)17,450,6648 (0.61%)237,067128 (9.81%)43,227,008148 (11.34%)68,436,68066 (5.06%)30,635,352Access my profileinformation*Access my data anytimeManage my pagesFigure 4. Post-Installation Privacy Settings for Apps as of5/10/2011.Number of appsrequesting category(percentage of appsrequesting category)Access my photosand videosAccess my friends’informationAccess posts in myNews FeedOnline Presence16 (1.23%)4,003,824Access my family &28 (2.15%)6,617,296relationshipAccess Facebook8 (0.61%)1,739,160ChatSend me SMS10 (0.77%)1,195,720messages* User information accessed by this category may vary based on differentapp requests.

As shown in Table 1, more than 850 million times users wereasked to release their basic information to applications. Further,the top three most frequently requested extended permissions are:“Send me email”, “Access my profile information”, and “Post tomy Wall”.4. THIRD-PARTY APPS' PRACTICES FORPRIVACY NOTICE AND CONSENTTo examine the current privacy notice and consent practices bythird-party apps on Facebook, we developed our own Facebookapp “Permission Experiment” and performed a series of tests toaddress the following two questions:Question 1 (Q1): To which extent could third-party apps overrideusers' global privacy settings on Facebook?Question 2 (Q2): To which extent does the authentication dialogtruly reflect the third-party apps' information practices?We present our findings in the sub-sections below.4.1 Tests of Privacy Violations (Q1)4.1.1 A Case of “Happy Calendar 2011”User A prefers to block disclosure of her birthday. Accordingly,her privacy setting for this information category is “Only me”,which means her birthday cannot be seen by other users onFacebook except herself. When this user adds the app “HappyCalendar 2011” to her profile, she is asked to grant the apppermissions to access her and her friends’ birthdays and to publishthem. Like most users, User A immediately grants the app allrequested permissions. Later, User A finds out that “HappyCalendar 2011” created an album in her profile and posted all herfriends’ birthdays that she can access, as well as her own, in acalendar image with their profile pictures being visible in thecorresponding date fields (see Figure 5). Moreover, User A’sfriends received a wall post notifying them of the creation of thisalbum and how they can access it. As a result, the “birthday”,which User A intended to keep private, is now accessible by herfriends. We consider this case as a privacy violation in which thethird-party app overrides users' global privacy settings.4.1.2 Further Tests of Privacy ViolationsIn the above case, we used “birthday” as a representative type ofpersonal information to supply an example of third-party appsoverriding users' privacy settings. We further utilized our own app“Permission Experiment” to run several similar tests for othertypes of information. Our results indicate that the privacy breachdemonstrated in the case of “Happy Calendar 2011” isgeneralizable to many different types of information requests. Aslong as a user grants the app the permission to access her own andher friends’ data, in conjunction with a publishing permission,then user’s profile information like “birthday” but also othercontents (e.g., photos, videos, comments, and everything sheshared), could be accessed and released by that app. Thus, weconclude with respect to Q1 that privacy violations may existwhen there is conflict between users’ privacy settings and apps’data collection and publishing practices. Our tests confirm thatFacebook’s powerful API enables application developers tocollect and publish user data in an aggressive fashion.4.2 Tests of Reflection (Q2)Question 2 asks about the extent to which the authenticationdialog truly reflects the third-party apps' information practices. Toaddress this question, we use our app “Permission Experiment” torequest different extended permissions from a hypothetical useraccount (User A) and examine the scope of information that canbe accessed when the permission is being granted. The followingprocedures state the process of our tests:Step 1. Different extended permissions were added to the sourcecode of our app “Permission Experiment” for requesting extendedpermissions from User A.Step 2. Observe how the authentication dialog changedcorrespondingly.Step 3. The app “Permission Experiment” was added to the user’sprofile.Step 4. Referred to the Facebook developer’s documentation tocarefully examine these extended permissions, e.g., what kind ofuser information can be accessed by the app.Step 5. Went to User A’s “Apps and Websites” settings to observewhich extended permission(s) can be removed.Next, we discuss our findings.4.2.1 Chaotic DisplayWhen developers change the source code to request differentpermissions for accessing users’ personal information orpublishing rights, the authentication dialog will change, however,the display can be chaotic. For example, when the app is asking toaccess photos and videos uploaded by the user’s friends as well asthose photos and videos friends were tagged in, the display ofthese two groups of permissions would look confusing, ashighlighted in Figure 6.Regarding the phrase of “Photos, Videos and Photos and Videosof Them” marked by the red line in Figure 6, we anticipate usersto experience confusion concerning its implications. Further, thesomewhat awkward treatment of English grammar does verylikely reduce users’ understanding. Thus, it might be very difficultfor them to understand the meaning and implication of theseextended permissions.Figure 5. A Case of Privacy Breach by Third-Party Apps.

and comment have their own properties and further connectedobjects, which distribute this permission further. In Figure 8, wedemonstrate the scope of accessible information after grantingpermission.Figure 6. Chaotic Display of Extended Permissions (Markedin Red) as of 5/10/2011.4.2.2 Insufficient ReflectionTo further address our second question (Q2), we use a simple caseof “Access my photos” to demonstrate whether the authenticationdialog will truly reflect the third-party apps' information practices.When our app “Permission Experiment” requests an extendedpermission to access user photos (“user photos”), users will see acorresponding authentication dialog (as shown in Figure 7) whenthey add the app.Based on our case analysis of “Access my photos”, we concludethat the prompting messages displayed in the authentication dialogfail in informing users about the actual scope of personalinformation that will be accessed by the app. If one app asks forextended permissions to access a certain object, with thatpermission being granted, the app can access not only all of itsnon-permission required properties but also its connected objects’properties.3 Furthermore, if the second-level objects are connectedto some third-level objects that are not included in the permissionrequest, those third-level objects’ properties will be available tothe app. And this information access chain will not stop until itreaches an object that does not have any further object connectingto it.4.2.3 Limited ControlIn the current design of the authentication dialog, we found thatthere is no way for users to limit the apps' information access orpublishing abilities during the installation process. Even the postinstallation information settings cannot sufficiently help users tocontrol what information they share with apps. In “Settings forWebsites and Apps”, users could only remove some categories ofthe extended permission(s). But users have no control options forthose extended permissions marked as “required” (see Figure 4).Surprisingly, even developers cannot define removable orrequired extended permissions. In our tests, without any specificdefinition in our source code, when we asked for differentextended permissions, some of these were marked as required andthus cannot be removed from the “Settings for Websites andApps”. In contrast, other extended permissions were available forremoval by users. So far, we have not found the patterns regardingwhen and what extended permissions could be removed by users.5. PROPOSED NEW DESIGNS5.1 Design PrinciplesFigure 7. The Authentication Dialog for the ExtendedPermission “user photos” as of 5/10/2011.In this dialog window, the extended permission asking for accessto user photos is explained as data access request for “Photosuploaded by me”. This explanation is confusing because usersmight easily entertain the belief that only the photos they haveshared on Facebook would be accessed by that app.However, in fact, with this simple “user photos” permission beinggranted, the real amount of information that the app could accessis far more substantial and exceeds the shared photos themselves.More specifically, the “user photos” permission actually enablesthe app to access all albums objects the user has created. For eachalbum object, it has ten properties and three connected objects(photo, comment, and picture) which do not require anypermission. And within those three connected objects, both photoOur analyses and tests of third-party apps' current practices forprivacy notice and consent have identified a number of problemsthat exist in the current design of the authentication dialogs.Although, we are aware of the fact that there is no panacea forprivacy settings, there is room for serious improvement. Ourresults suggest a number of heuristics to improve the design andthe effectiveness of privacy notice and consent:Known information – The authentication dialog should provideexplicit signals for users to distinguish what data would beaccessed by the app and how the data would be used.Control before allowing – The authentication dialog shouldprovide options for users to control the app’s data reading andwriting practices before adding the app to their profiles.3"Non-permission required properties" can be fetched without anyextended permission (e.g., all properties related to comments onFacebook, including id, from, message, created time, likes, user likes andtype). To be more specific, if a user grants an app access to her photos,then this app can also access all the comments posted under this user'sphotos.

Figure 8. The Real Amount of Information Could Be Released After Granting Permission “user photos” as of 5/10/2011.Conflict caution – The authentication dialog should providewarning signals to the users when data and publishing permissionsrequested by the app will violate their global privacy settings.Privacy indication – The authentication dialog should reflect auser’s current privacy settings.The first three design principles were developed to address theidentified flaws that exist in current designs of authenticationdialogs. The fourth design principle was developed to test whetherusers want the authentication dialog to further reflect their privacysettings. In order to better isolate the implications of the fourthdesign principle, we split our analysis by providing two newdesigns addressing different aspects of our suggestions.5.2 Alternative InterfacesKelley et al. developed a privacy “nutrition label” that presents toconsumers the ways organizations collect, use, and share personalinformation [16]. Their design, inspired by the field of thenutrition warnings and advice, aims to: 1) clearly highlight themeaning of different labels so that users can easily understand thedifferent sets of information; 2) use different font highlights toseparate sets of information in order to expedite the users’navigation through the list; and 3) have a bold and clear title toinform the user of the purpose of the information in each section[2, 3, 8, 11]. In this research, we aim to include similar designelements in our designs.As Carroll highlighted in his book [9], “people rely on analogieswith familiar, readily envisaged domains to build mental modelsof less-familiar, less-visible domains”. Following this designguideline, we have adopted icons and color themes that are wellconsistent with users’ mental models in their familiar and readilyenvisaged domains. For instance, as a sign for alert in our dailylife, we have used the red exclamation mark to indicate theconflict between users’ privacy settings and apps’ requests fordata access.Envisioned by the proposed design heuristics and previousanalyses, we now present our alternative interfaces for privacyauthentication dialogs by third-party apps on Facebook.5.2.1 Monochrome Authentication Dialog (MONO)The MONO interface design of the authentication dialog aims tofulfill the first three design principles (see Figure 9).Below we describe our major design elements.The Layout of Permissions: All types of data (basic informationand data reading permissions) required by the app are listed in thefirst column. The first row displays the information regarding howthe app will use the data (including data writing and pagemanagement permissions).

People ”, or “Only Me”. For example, if a user’s privacy settingfor “Birthday” is “Friends Only” or “Friends of Friends”, then inthe authentication dialog, the background of the checkboxes in the“Birthday” row will be marked yellow. In this case, the app wouldbe able to access this personal information item while other usersmay have partially restricted access. Even though the originaluser's privacy setting is not directly violated by the app, theremight be some potential privacy risks for the user to allow the appto access these data.Figure 9. Proposed MONO Interface Design.The Tick Mark and Checkbox: Un-clickable tick marksrepresent those types of information that will be accessed andused by the app. Users have to give out corresponding informationto use the app. The checked check box means that users will allowthe app to access and use certain information. The un-checkedcheck box means that users will not allow the app to access or usethe corresponding information.The Red Exclamation Point: When the information requested bythe app conflicts with the user’s privacy settings, the redexclamation point alerts users about the potential conflict.Shortcut Buttons: We add two buttons to help users control howthe app accesses and publishes their information. When clicking„Follow My Privacy Settings‟, those check boxes with the redexclamation point alert will be unchecked. Under this situation,the app will not be allowed to use these specific types ofinformation. When clicking „Uncheck All‟, all the check boxeswill be unchecked, i.e., only required types of information will beshared.5.2.2 Polychrome Authentication Dialog (POLY)Our second design of the authentication dialog, the POLY design,is an enhanced version of the MONO design, with a three-colorscheme to reflect users’ privacy settings, which addresses thefourth design principle (see Figure 10).GREEN indicates the current privacy setting for thecorresponding information is “Everyone” and it will NOT beviolated by adding the app to the user’s Facebook account.RED indicates the current privacy setting for that information is“Only Me” or “Specific People ” and it will be violated byadding the app to the user’s Facebook account.YELLOW indicates the current privacy setting for thatinformation is something beyond “Everyone”, “SpecificFigure 10. Proposed POLY Interface Design.6. PRELIMINARY USER EVALUATIONTo gain a preliminary understanding of user feedback, weconducted a qualitative study to evaluate the MONO and POLYdesigns. The intent of this evaluation approach is to ensure thatthe design principles identified in the conceptual analysis areadequately met in the opinion of the target user population. Weconsidered protecting one’s privacy as a sensitive topic; there maybe social implications to responses people give. When collectingdata about sensitive topics, it is appropriate to utilize open endedquestions to permit respondents expressing themselves in a waythat they do not feel threatened, and allowing them to say as muchor as little as they would like and not be confined to a limited setof answers that are available in a Likert-type survey design.6.1 Participants and ProcedureParticipants were recruited from junior/senior levels ofundergraduate classes at a public university in the United States.We specified that participants must be active Facebook users.Two extra credit points were awarded for their participation in thisstudy. There were in total eleven participants who consented topartake in our user study. Among these eleven participants, twowere female and nine were male; and they identified their ages as20 to 24.

Participants were first asked to review the third-party apps theyadded to their Facebook accounts and recall their installation anduser experience, fo

the 1800 most popular Facebook apps to record their data collection practices concerning users and their friends, and ii) developing our own Facebook app to conduct a number of tests to identify problems that exist in the current design of authentication dialogs for third-party app