大数据在社交网络的应用
社交网络应用程序已成为企业生活的一部分。 这些应用程序收集和处理用户主动和被动上传的信息，然后根据分析结果在用户之间建立关系。 它们可以帮助员工保持联系并建立融洽的关系，即使他们可能由于地理位置或不太传统的工作条件（例如在家工作）而分隔开来。
但是，有关这些应用程序存在一些担忧：它们收集的信息是否被滥用？ 应该限制收集和提供给用户的信息类型吗？ 是否有隐私问题？
社交网络应用程序收集的信息需要受到控制信息访问权限的策略的保护。 这些控件中的某些控件可能是为了保护个人用户免遭其信息的不当使用。 其他人可能是为了保护公司利益。 使用社交网络应用程序的开发人员需要意识到这些问题，并具有在事件发生之前进行处理的策略。
在本文中，我将探讨为社交网络应用程序设计隐私功能的方法，包括通过信息分类和用户类型区分来保护隐私。 我还将向您展示不同隐私要求的比较。 然后，我将使用一个名为“ Friend Bridge”的示例应用程序，该应用程序提供了通过从直接朋友中查找间接朋友来扩展某人的社交网络的功能。 基于此应用程序，我们将探索一种在社交网络应用程序上实现隐私功能的方法，并向您展示一些推荐的做法。
方法
社交网络应用程序不仅应提供有用的功能，而且还应保护人们的信息免遭滥用。 但是，社交网络的核心思想是共享。 如果信息受到过度保护，则社交网络的功能会降低。 因此，我们需要先对信息进行仔细分类，然后对信息应用不同的隐私策略，以在共享与隐私控制要求之间取得平衡。
信息分类
通常，我们可以根据需要将信息分类为多种类型。 在本文中，我将使用一个简单的示例，并将信息分为两种类型：公共和私有。
- 公共信息是用户清楚知道可以提供给系统中的每个人的任何信息。 例如博客和个人介绍信息。 此类信息不受严格保护，并且任何系统用户通常都具有足够的特权来读取公共信息。
公共信息还包括从公共信息中得出的信息，例如，用户的兴趣可以通过分析他或她的博客，个人介绍或书签信息来获得。 - 私人信息包括用户的私人数据，例如，电子邮件地址，电话号码和通信记录。 此类信息只能由系统在特定保护下进行处理。
私人信息还包括从私人信息导出的信息，例如，正在建立基于对用户的通讯记录分析的友谊构成的私人信息。
用户类型分类
我将这些权限授予信息所有者，而不是由系统开发人员或管理员定义默认访问策略，并让他们决定如何使用和保护其信息。 这就是用户类型分类的原因。 我们定义了四种类型的角色，用户可以选择在系统中扮演的角色。 用户可以在注册阶段或系统引用它们时选择他们的角色。
我们将有四种类型的用户：
- 贡献者 —将个人数据上传到系统并允许系统显示引用给他的信息的用户。
- 选择加入用户 -不将个人数据上传到系统，但允许系统显示引用给他的信息的用户。
- 退出用户 -限制系统使用其私人或公共信息，或显示引用给他的任何信息的用户。
- 无操作用户 -没有为自己想担任的角色提供任何选择的用户。
角色类型可以根据不同系统的要求而变化。 我有一种可配置的方式来满足不断变化的要求，我将在以下各节中进行说明。
样例应用
应用概述
图1.欢迎页面
图1显示了一个称为“ Friend Bridge”的社交网络应用程序，该应用程序提供了扩展用户社交网络的服务。 显示的当前用户是Bob，他已将其通信记录上载到系统。 他登录系统后，将显示从他的通讯记录中派生的直接朋友列表。
现在，Bob可以通过单击单选按钮之一来选择他的直接朋友之一，然后他可以单击“ 查找某人的朋友”以查找更多朋友。
图2.没有隐私控制的搜索结果
在图2中，Bob找到了培根的三个朋友： Daisy， Ellis和Gilbert，并显示了他们的电子邮件地址。 他可以联系这些人以扩展他的社交网络。
信息分类
该应用程序简单明了。 它通过显示其直接朋友的朋友来扩展用户的社交网络。 让我解释一下应用程序是如何工作的，以及幕后的隐私问题。
在此应用程序中，系统首先向找到的用户发出选择加入请求通知，以请求他们的通信数据上传。 在某些用户上载其通信数据之后，通过处理上载的通信数据，然后将其存储在以所有者的电子邮件地址命名的文本文件中，可以生成直接的朋友关系。 清单1显示了用户Bob的示例数据。
清单1. bob@friendbridge.com.txt
bob@friendbridge.com Bob US field@friendbridge.com,bacon@friendbridge.com,
james@friendbridge.com在此特定示例中，Bob和系统中的许多其他贡献者一样，都上载了他的通信数据。 他的通信数据由系统处理和分析，以生成存储用户之间关系的通信配置文件。 清单1是Bob在文件系统中存储的通信配置文件。
通信配置文件通过选项卡分为四个部分。 第一列是所有者的电子邮件地址，后跟所有者的名称。 鲍勃的国家/地区名称位于第三列，而第四列是电子邮件地址列表。 这些电子邮件地址属于直接与个人资料所有者进行通信的人员。
朋友关系文件中的内容归类为私人信息，因为它是根据通信数据（即私人数据）生成的。
分析安全要求并建立角色模型（定义用户类型）
正如我在上一节中提到的那样，我们将选择权交给用户自己，而不是要求管理员定义要显示的信息和信息。 这种方法减轻了管理员定义许多隐私策略的工作量，同时提供了更好的用户体验。
用户可以通过回复系统的选择加入通知来决定应在其信息上应用哪种隐私。 在此示例系统中，用户有三个选择：
- 用户可以选择不显示在任何搜索结果中（完全排除）。
- 用户可以选择显示在直接好友列表中，而不是在间接好友搜索（部分排他）中显示。
- 用户可以选择显示在直接朋友列表中，也可以包括在搜索间接朋友功能中（完全支持）。
基于这些可能的选择，在此示例中，我们将用户分为四种类型：
- 无操作用户-用户尚未回复选择加入通知。
- 选择加入用户-用户选择加入，但不喜欢上传个人通信数据。
- 贡献者—用户同意选择加入并将个人通信数据上传到系统。
- 退出用户-在任何情况下，系统都不希望用户转介该用户。
将隐私策略应用于应用程序
现在已经建立了隐私模型，我们需要以一种与我们的源代码一起使用的方式定义适用于角色类型的隐私策略。 清单2显示了一种将信息存储为XML的方法。
清单2. privacyPolicy.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2 <privacy-policy-config>
3
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>
9
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>
15
16 <privacy-policy-suite>
17 <country-list>Germany, France, UK</country-list>
18 <data-policy-name>1</data-policy-name>
19 </privacy-policy-suite>
20
21 <privacy-policy-suite>
22 < country-list >China, US, </ country-list >
23 <data-policy-name>2</data-policy-name>
24 </privacy-policy-suite>
25
26 </privacy-policy-config> privacyPolicy.xml由两种类型的元素组成： <data-policy-suite>和< privacy-policy-suite > 。 他们共同努力定义隐私政策。
<data-policy-suite>中包含三种类型的元素： <data-policy-name> ， <public-display-role>和<private-display-role> 。 第一个是<data-policy-suite>的ID。 它的值可以是数字或字母，并且在所有元素中应该唯一。 在此示例中，我们使用数字作为<data-policy-name>的值的ID。 第二个元素<public-display-role>定义公共数据的隐私策略，其值是1到4之间的整数。整数代表角色类型：1（无操作用户），2（选择加入用户） ），3（贡献者）和4（退出用户）。 如果此元素中存在整数，则表示此角色类型的人的公共数据将显示在系统中。 根据<data-policy-suite>从第4行到第8行的定义，在<public-display-role>元素中存在数字1、2、3和4。 根据此数据策略套件，所有公共数据都将显示在系统中。 但是，就像在第10行到第14行中定义的<data-policy-suite> ，当系统显示搜索结果时，将过滤掉退出用户的公共数据。
<data-policy-suite>的第三个元素是<private-display-role> 。 其值类型具有与<public-display-role>相同的定义，但是由于对私有信息的复杂安全要求，因此必须将其与<privacy-policy-suite>以描述私有信息的隐私策略。 根据我们的要求部分中的定义，选择加入用户，贡献者和选择退出用户是那些已明确配置其选项以允许或不允许系统处理其私人信息的用户。 但是，对于那些未通过电子邮件或其他方式回复系统的选择加入请求通知的人员，他们将被分类为“无操作”用户。 为了处理这些用户的私人信息，我们要遵循不同的法律，具体取决于用户所居住的国家/地区。例如，在某些国家/地区，如果用户未回复选择加入的请求，则可以认为他是静默接受选择加入的请求。 相反，在其他国家/地区，系统仅在用户积极回答选择加入请求时才将其视为选择加入。 因此，即使他们在系统中具有相同的用户类型（无操作用户），我们也必须为来自不同国家/地区的人们定义针对私人信息的不同隐私策略。 在这种情况下， <privacy-policy-suite>必须与<data-policy-suite>一起描述私人信息的隐私策略。
<privacy-policy-suite>由两个元素组成： <country-list>和<data-policy-name> 。 第一个元素存储县列表，第二个元素通过其ID将存储在第一个元素中的国家/地区引用到<data-policy-suite> 。 如清单2从第16行到第19行所定义，我们将德国，法国和英国附加到data-policy-suite1 。 这意味着，在这些国家/地区中，如第7行中所定义，系统只能显示加入用户和参与者的私人信息。然后，在第21行至第24行中定义了另一个<privacy-policy-suite> ，指示在中国和美国，可以显示“无操作”用户，“选择加入”用户和“参与者”的私人信息。 在现实世界中，隐私策略可能与此示例不同。 管理员可以修改此配置文件，以使该应用程序适合任何隐私要求。
在编程级别，我们构造一个“过滤器”功能以删除不适合privacyPolicy.xml定义的呈现信息。
清单3显示了用于实现PrivacyPolicy.xml中定义的隐私策略的方法
清单3. 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);
23
24 }catch(IOException e){
25 e.printStackTrace();
26 }
27 if(displayRoleSet.contains(userRole)){
28 retList.add(email);
29 }
30 }
31 return retList;
32 } 我们假设在隐私功能正常运行之前，我们可以获得系统默认行为返回的电子邮件地址列表。 然后，我们将列表输入为filterByPP的第一个参数，并将数据类型输入为第二个参数。 对于输入列表中每个人的信息，我们首先通过该人的电子邮件地址（清单3的第10行）检索国家/地区名称。 然后，将国家名称和dataType输入为另一种方法的参数： FBUtils.getDisplayRoleSet(country, dataType) （清单3的第15行）。 此方法返回一组角色（ displayRoleSet ），用于描述根据人员所在的国家/地区和当前dataType允许显示的类型。 然后，该方法通过调用FBUtils.getRole(email) （清单3的第22行）并检查返回的角色是否包含在displayRoleSet检索当前人员的角色类型。 如果其中包含该人的信息，则将其信息添加到返回列表中，然后显示出来；否则，将根据隐私策略对其进行过滤。 最后， filterByPP方法返回结果。
让我们按照此逻辑来查看隐私控制功能在系统中的工作方式。 回头看看我们的朋友鲍勃。 他可以看到从上传的通讯记录中获得的直接朋友列表（图1）。 在那里，他有三个直接的朋友：菲尔德，培根和詹姆斯。 鲍伯可以通过搜索可以从他的直接朋友培根那里认识的人来选择扩展他的社交网络。 为此，他选择培根之前的单选按钮，然后单击查找培根的朋友 。
系统首先从培根的通讯档案中检索直接朋友的列表。
清单4. bacon@friendbridge.com.txt
bacon@friendbridge.com Bacon China daisy@friendbridge.com,ellis@friendbridge.com,
gilbert@friendbridge.com 清单4是Bacon的通信配置文件。 培根的个人资料文件中存储了三个直接朋友的电子邮件地址。 这三个电子邮件地址将是系统默认行为返回的电子邮件列表。 在它成为最终结果之前，我们需要通过私人信息的隐私策略过滤电子邮件列表。 因此，方法filterByPP的输入是三个电子邮件地址的列表，而dataType是私有的。
在程序循环中，第一封电子邮件是daisy@friendbridge.com。 方法filterByPP从她的个人资料文件中检索她的国家/地区名称（在此示例中为英国）。 清单5是Daisy的配置文件。
清单5. daisy@friendbridge.com.txt
daisy@friendbridge.com Daisy UK 然后，方法filterByPP从displayRoleSet中检索displayRoleSet的私有数据类型的displayRoleSet。 如privacyPolicy.xml的第17行和第18行中所定义，英国连接了ID为1（简称为data-policy-suite1 ）且值为<private-display-role >的<data-policy-suite> <private-display-role > data-policy-suite1中的2和3（清单3的第7行）。 结果， displayRoleSet值为2、3。然后该方法从options.txt中检索daisy@friendbridge.com的选项，该选项存储所有用户的选择加入信息。
清单6. options.txt
adams@friendbridge.com 2
bacon@friendbridge.com 3
carter@friendbridge.com 4
daisy@friendbridge.com 1
ellis@friendbridge.com 2
field@friendbridge.com 3
gilbert@friendbridge.com 3
harper@friendbridge.com 4
isaac@friendbridge.com 2
james@friendbridge.com 3
mark@friendbridge.com 2
michael@friendbridge.com 4
noah@friendbridge.com 4
bob@friendbridge.com 3 清单6是options.txt， filterByPP方法filterByPP得知daisy@friendbridge.com的角色类型为1。由于displayRoleSet的2和3中不包含1，因此displayRoleSet将Daisy的私人信息显示为搜索结果；否则，将不显示Daisy的私有信息。 通过该方法进行过滤。 该方法在ellis@friendbridge.com和gilbert@friendbridge.com上应用了相同的过程，并且gilbert@friendbridge.com也符合要显示的隐私策略。 图3显示了启用隐私控制功能后的不同搜索结果。 搜索结果与图1不同。
图3.启用隐私控制的搜索结果
这就是隐私控制功能的工作原理。
隐私功能的亮点
使用配置文件来促进隐私策略是我们设计中最具创新性的部分。 由于<data-policy-suite>和<privacy-policy-suite>是可配置和可重用的，因此在面对三种类型的设计更改时，可以限制代码更改：
- 角色类型变更
当隐私要求更改时，角色类型定义也会更改。
当系统管理员对隐私要求的更改不满意当前角色类型设计时，他可以通过修改配置文件轻松地更改用户类型定义。 例如，管理员可能希望从系统中删除“无操作”用户。 他可以简单地从privacyPolicy.xml中删除所有“ 1”，然后将其他用户类型分配给options.txt中所有“无操作”用户的人。 由于我们的应用程序仅在存在特定角色类型时显示信息，因此只需从privacyPolicy.xml中删除角色类型即可删除角色类型。 - 信息分类变更
当系统中包含具有不同隐私策略要求的称为中间数据的新信息类型时，管理员可以在<data-policy-suite>内添加新元素<inter-display-policy>，以定义值，然后输入“ inter”作为filterByPP方法的第二个参数。 通过将其与privacyPolicy.xml中的<inter-display-policy>连接起来，过滤器方法filterByPP可以与新添加的数据类型配合使用。 - 显示政策变更
我们可以实施显示政策更改。 例如，我们可能希望系统显示所有类型的用户公共信息。 第一种方法是在privacyPolicy.xml中构造一个新的<data-policy-suite>，然后添加一个值为：1、2、3、4的<public-display-role>。但是，我们还有另一个方式。 因为<data-policy-suite>和<privacy-policy-suite>本身是可配置的，所以我们可以通过在其<public-display-role>元素上添加值4来重用现有元素data-policy-suite1。以便于更改显示政策。
结论
本文探讨了在社交网络应用程序中实现隐私控制的分步方法。 首先，我们确定了隐私控制要求。 然后，我们遵循一些方法来对那些需求进行建模。 我们在一个真实的示例中应用了我们的策略和方法，并检查了从设计到编程的实现隐私功能的整个过程。 最后，我们对实现进行了一些分析，并研究了我们解决方案的可扩展性。
我希望本文中提到的方法能够激发社交网络开发人员考虑隐私控制的设计和实现。
翻译自: https://www.ibm.com/developerworks/web/library/wa-socialprivacy/index.html
大数据在社交网络的应用
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
