Design and implement privacy control in social network applications


Social network applications are becoming a part of corporate life. These applications collect and process information uploaded by users actively and passively and then set up relationships between users based on the analyzed results. They are helping employees stay connected and build rapport even though they may be separated by geography or less traditional work conditions, such as working from home.

However, there are concerns about these applications: Is the information they collect something that can be abused? Should there be limits placed on the type of information that is collected and made available to users? Are there privacy concerns?

Information gathered by social network applications needs to be protected by policies which control access to information. Some of these controls may be to protect individual users from inappropriate use of their information. Others may be to protect the interests of the company. Developers working with social network applications need to be aware of these issues and have strategies for dealing with them before incidents occur.

In this article I'll explore methodologies of designing privacy features for social network applications, including protecting privacy through information classification and user type differentiation. I'll also show you a comparison of different privacy requirements. Then I'll use an example application called "Friend Bridge," which provides the functionality of extending someone's social network by finding indirect friends from direct friends. Based on this application, we'll explore a way to implement privacy features on a social network application, and I'll show you some recommended practices.


A social network application should not only provide useful features, but also protect people's information from abuse. However, the core idea of a social network is sharing. If information is over-protected, the power of the social network is decreased. So, we need to carefully classify the information first, and then apply different privacy policies on it to balance the sharing with privacy control requirements.

Information classification

Generally, we can categorize information into as many types as needed. I'll use a simple example in this article and classify the information into two types: public and private.

  • Public information is any information provided by the user with a clear mind that it could be displayed to everyone in the system. Examples are blogs and personal introduction information. This type of information is not strictly protected, and any system user usually has enough privileges to read public information.
    Public information also includes information derived from pubic information, for example, a user's interests might be obtained by analyzing his or her blog, personal introduction, or bookmarks information.
  • Private information includes a user's private data, for example, e-mail address, phone number, and communication records. This type of information can only be processed by the system under certain protections.
    Private information also includes information derived from private information, for example, friendships that are set up based on analysis of a user's communication records constitute private information.

User type classification

Instead of defining default access policies by system developers or administrators, I'll give these rights to the information owners, and let them decide how their information should be used and protected. This is the reason for user type classification. We define four types of roles that the users can choose to play in the system. Users have the opportunity to choose their roles during the registration phase, or at the time they are referenced by the system.

We'll have four types of users:

  • Contributor— a user who uploads personal data to the system and allows the system to display information referenced to him.
  • Opt-in user— a user who does not upload personal data to the system, but allows the system to display information referenced to him.
  • Opt-out user— a user who restricts the system to use his private or public information, or display any information referenced to him.
  • No Action user— a user who does not give any options about the role he would like to be.

Role types can vary according to the requirements for different systems. I have a configurable way to fulfill the changing requirements which I'll explain in the following sections.

The sample application

Application overview

Figure 1. Welcome page
Screenshot of the Friend Bridge, showing a greeting with a few names with radio dials and a button labeled 'Find friends of Bacon'
Screenshot of the Friend Bridge, showing a greeting with a few names with radio dials and a button labeled 'Find friends of Bacon'

Figure 1 shows a social network application called "Friend Bridge," which provides the service to extend a user's social network. The current user shown is Bob, who has uploaded his communication records to the system. After he signs in to the system, a list of direct friends derived from his communication records is displayed.

Now Bob can choose one of his direct friends by clicking one of the radio buttons, and then he can click Find friends of someone to find more friends.

Figure 2. Search result without privacy control
The screenshot from Figure 1 now has search results at the bottom                     giving the names and email addresses of three newly found friends.
The screenshot from Figure 1 now has search results at the bottom giving the names and email addresses of three newly found friends.

In Figure 2, Bob finds three friends of Bacon: Daisy,Ellis, and Gilbert, and their e-mail addresses are displayed. He could contact these people to extend his social network.

Information classification

The application is straight forward and simple. It extends a user's social network by displaying friends of his direct friends. Let me explain how the application works, as well as the privacy issues behind the scenes.

In this application, the system first sends out an opt-in request notification to users it finds, asking for their communication data upload. After some users upload their communication data, direct friend relationships are generated by processing the uploaded communication data and then storing it in a text file named with the owner's e-mail address. Listing 1 shows example data for the user Bob.

Listing 1.	Bob	US,,

In this particular example, Bob has uploaded his communication data, as have many other contributors in the system. His communication data is processed and analyzed by the system to generate the communication profile that stores the relationship between users. Listing 1 is Bob's communication profile as stored in the file system.

The communication profile is separated into four parts by tabs. The first column is the e-mail address of the owner, followed by the owner's name. Bob's country name lies in the third column, and the forth column is a list of e-mail addresses. These e-mail addresses belong to those people who have communicated with the profile owner directly.

The content in the friend relationship file is classified as private information because it is generated from communication data, which is private data.

Analyze the security requirements and set up role models (define user types)

As I mentioned in the previous section, instead of requiring the administrator to define whose and what information should be displayed, we give that choice to the users themselves. This method relieves the administrator of the hard work of defining many privacy policies, and meanwhile, provides better user experiences.

Users can decide which privacy should be applied on their information by replying to the system's opt-in notification. Users have three choices in this sample system:

  1. A user can choose not to be displayed in any search result (totally exclusive).
  2. A user can choose to be displayed in the direct friends list but not in indirect friend searches (partially exclusive).
  3. A user can choose to be displayed in the direct friends list and be included in the searching indirect friend feature (full support).

Based on these possible choices, we classify users into four types in this example:

  1. No action user — The user has not replied to the opt-in notification yet.
  2. Opt-in user — The user chooses to opt-in, but does not like to upload personal communication data.
  3. Contributor — The user agrees to opt-in and uploads personal communication data to the system.
  4. Opt-out user — The user does not want to be referred by the system under any condition.

Apply privacy policies to the application

Now that the privacy model has been set up, we need to define privacy policies applying to the role types in a way that works with our source code. Listing 2 shows one approach to storing this information as XML.

Listing 2. privacyPolicy.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2  <privacy-policy-config>
4	<data-policy-suite>
5		<data-policy-name>1</data-policy-name>
6		<public-display-role>1,2,3,4</public-display-role>
7		<private-display-role>2,3</private-display-role>
8   </data-policy-suite>
10	<data-policy-suite>
11		<data-policy-name>2</data-policy-name>
12		<public-display-role>1,2,3</public-display-role>
13		<private-display-role>1,2,3</private-display-role>
14	</data-policy-suite>
16	<privacy-policy-suite>
17		<country-list>Germany, France, UK</country-list>
18		<data-policy-name>1</data-policy-name>
19	</privacy-policy-suite>				
21	<privacy-policy-suite>	
22		< country-list >China, US, </ country-list >
23		<data-policy-name>2</data-policy-name>
24	</privacy-policy-suite>	
26 </privacy-policy-config>

The privacyPolicy.xml consists of two types of elements: <data-policy-suite> and < privacy-policy-suite >. They work together to define the privacy policies.

Included in the <data-policy-suite>, there are three types of elements: <data-policy-name>, <public-display-role>, and <private-display-role>. The first one is the ID of the <data-policy-suite>. Its value can be a number or letter and should be unique among all the elements. In this example, we use a number as the ID of the value of <data-policy-name>. The second element, <public-display-role>, defines the privacy policy for public data, and its value is an integer from 1 to 4. Integers stand for role types: 1 (No action user), 2 (Opt-in user), 3 (Contributor), and 4 (Opt-out user). If an integer exists in this element, it means the public data of people with this role type will be displayed in the system. As defined in the <data-policy-suite> from line 4 to line 8, numbers 1, 2, 3, and 4 exist in the <public-display-role> element; all the public data will be displayed in the system according to this data policy suite. But as in the <data-policy-suite> defined from line 10 to line 14, the Opt-out users' public data will be filtered when the system is displaying search results.

The third element of <data-policy-suite> is <private-display-role>. Its value type has the same definition as the <public-display-role>, but because of complex security requirements for private information, it has to be connected with <privacy-policy-suite> to describe the privacy policy of private information. As defined in our requirements section, Opt-in users, Contributors, and Opt-out users are those users who have explicitly configured their options to allow or not allow the system to process their private information. However, for those people who have not replied to the system's opt-in request notification, sent by e-mail or other ways, they are classified as No action users. To deal with these users' private information, we have different laws to follow, depending on which country the user lives in. For example, in some countries, if a user does not reply to the opt-in request, he can be regarded as silently accepting the opt-in request. In contrast, in other countries, a system regards a user as an opt-in only when he replied to the opt-in request positively. So we have to define different privacy policies on private information for people from different countries, even if they have the same user type (No action user) in the system. In this situation, <privacy-policy-suite> has to work with <data-policy-suite> to describe the privacy policy of private information.

<privacy-policy-suite> consists of two elements: <country-list> and <data-policy-name>. The first element stores a list of counties, and the second element refers countries stored in the first element to a <data-policy-suite> by its ID. As defined in Listing 2 from line 16 to line 19, we attach Germany, France, and the UK to data-policy-suite1. That means, in these countries, only Opt-in users' and Contributors' private information can be presented by the system as defined in line 7. Then, there is another <privacy-policy-suite> defined from line 21 to line 24 indicating that in China and the US, private information of No action user, Opt-in user, and Contributor can be displayed. In the real world, the privacy policy could be different from this example. The administrator can modify this configuration file to make this application suit any privacy requirements.

At the programming level, we construct a "filter" function to delete information that is not suitable for presenting as defined by privacyPolicy.xml.

Listing 3 shows the method used to implement privacy policies defined in PrivacyPolicy.xml

Listing 3. Method of filterByPP
1	/**	Filter the friendList by display policies
2	 * @param friendList	the friendList needs to be filtered
3	 * @return	a friendList that fulfills privacy policies
4	 */
5	public static List<String> filterByPP(List<String> friendList, String dataType){
6		List<String> retList = new ArrayList<String>();
7		for(String email: friendList){
8			String country = null;
9			try{
10				country = FBUtils.getCountry(email);
11			}catch (IOException e){
12				e.printStackTrace();
13			}
14			Set<Integer> displayRoleSet = new HashSet<Integer>();
15			displayRoleSet = FBUtils.getDisplayRoleSet(country, dataType);
16			if(0 == displayRoleSet.size()){
17				System.err.println("no display role");
18				continue; //no information should be displayed
19			}
20			int userRole = 0;
21			try{
22				userRole = FBUtils.getRole(email);
24			}catch(IOException e){
25				e.printStackTrace();
26			}
27			if(displayRoleSet.contains(userRole)){
28				retList.add(email);
29			}
30		}
31		return retList;
32	}

We assume that before the privacy feature is functional, we can get a list of e-mail addresses returned by the system's default behavior. Then we input the list as the first parameter of the filterByPP, and input the data type as the second parameter. For every person's information in the input list, we first retrieve the country name by the person's e-mail address (line 10 of Listing 3). Then we input the country name and dataType as parameters to the other method: FBUtils.getDisplayRoleSet(country, dataType) (line 15 of Listing 3). This method returns a set of roles (displayRoleSet) describing which types are allowed to present according to the person's country and current dataType. Then the method retrieves the current person's role type by invoking FBUtils.getRole(email)(line 22 of Listing 3) and checking whether the returned role is contained in the displayRoleSet. If it is contained there, the person's information is added to the return list and then presented, and otherwise, it will be filtered according to the privacy policy. Finally, the filterByPP method returns the result.

Let's follow this logic to see how the privacy control feature works in the system. Look back at our friend, Bob. He can see a list of direct friends (Figure 1) derived from his uploaded communication records. There he has three direct friends: Field, Bacon, and James. Bob can choose to extend his social network by searching who can be known from his direct friend Bacon. To do so, he chooses the radio button before Bacon and clicks Find friends of Bacon.

The system first retrieves a list of direct friends from Bacon's communication profile.

Listing 4.	Bacon	China,,

Listing 4 is Bacon's communication profile. Three direct friends' e-mail addresses are stored in Bacon's profile file. These three e-mail addresses will be the e-mail list returned by the system's default behavior. Before it becomes the final result, we need to filter the e-mail list by privacy policies of private information. Therefore, the input of method filterByPP is a list of three e-mail addresses, and dataType is private.

In the program loop, the first e-mail is The method filterByPP retrieves her country name (which is UK in this example) from her profile file. Listing 5 is Daisy's profile file.

Listing 5.	Daisy	UK

Then the method filterByPP retrieves the displayRoleSet of private data type for the UK from privacPolicy.xml. As defined in line 17 and line 18 of privacyPolicy.xml, the UK is connected with a <data-policy-suite> with ID 1(data-policy-suite1 for short), and the value of <private-display-role> in data-policy-suite1 is 2 and 3 (line 7 of Listing 3). As a result, the value of displayRoleSet is 2, 3. Then the method retrieves's option from options.txt, which stores all users' opt-in information.

Listing 6. options.txt	2	3	4	1	2	3	3	4	2	3	2	4	4	3

Listing 6 is the options.txt, from which the filterByPP method knows's role type is 1. As 1 is not contained in the displayRoleSet of 2 and 3, Daisy's private information should not be displayed as the search result; it is filtered by the method. The method applies the same processes on and, and also fulfills the privacy policy to display. Figure 3 shows the different search results after the privacy control feature is enabled. The search result is different from Figure 1.

Figure 3. Search result with privacy control enabled
We see a screenshot of the Friend Bridge application after a search, but this time only two names are returned: Ellis and Gilbert.
We see a screenshot of the Friend Bridge application after a search, but this time only two names are returned: Ellis and Gilbert.

That's all for how the privacy control feature works.

The highlights of the privacy feature

Employing a configuration file to facilitate the privacy policy is the most innovative part of our design. As the <data-policy-suite> and <privacy-policy-suite> are configurable and reusable, it makes it possible to limit the code change when facing three types of design changes:

  1. Role type change
    The role type definition changes when the privacy requirement changes.
    When the system administrator is not satisfied with the current role type design as the privacy requirement changes, he can easily change the user type definitions by modifying the configuration files. For example, the administrator might want to delete No action users from the system. He can simply delete all the "1s" from privacyPolicy.xml and assign other user types to all the people who are No action users in the options.txt. As our application only displays information when there exists a specific role type, deleting a role type is done by simply deleting it from the privacyPolicy.xml.
  2. Information classification changes
    When a new information type called intermediate data, which has different privacy policy requirements, is being included in the system, the administrator can add a new element, <inter-display-policy>, within the <data-policy-suite>, defining the value for it and then inputting "inter" as the second parameter of the filterByPP method. The filter method filterByPP will work fine with the newly added data type by connecting it with <inter-display-policy> in the privacyPolicy.xml.
  3. Display policy change
    We can implement a display policy change. For example, we might want all types of a user's public information to be presented by the system. The first way to do this is to construct a new <data-policy-suite> in the privacyPolicy.xml and then add a <public-display-role> with value: 1, 2, 3, 4. However, we have another way. Because the <data-policy-suite> and <privacy-policy-suite> themselves are configurable, we can reuse the existing element, data-policy-suite1, by adding a value of 4 to its <public-display-role> element to facilitate the display policy change.


This article explored a step-by-step method to implementing privacy controls in a social networking application. First, we determined the privacy control requirements. Then we followed some methodologies to model those requirements. We applied our policies and methodologies in a real example and examined the whole process of implementing privacy features, from design to programming. Finally, we did some analysis of the implementation and looked at the extensibility of our solution.

I hope the methods mentioned in this article will inspire social network developers to consider privacy control design and implementation.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Web development
ArticleTitle=Design and implement privacy control in social network applications