Modeling Social Networking Privacy: Beyond Informal FAQ Logic

TL;DR

Privacy settings on social networks are notoriously difficult to navigate. This paper introduces a formal approach using SecureUML to transform vague, natural-language privacy policies into mathematically rigorous models. Using Facebook's posting and tagging rules as a case study, the authors demonstrate how formal logic can eliminate ambiguity and allow for automated verification of user privacy.

Background: The "Privacy-by-FAQ" Problem

Most social media users rely on Help Centers and FAQs to understand who can see their data. However, as the 2011 audit by the Irish Data Protection Commissioner (DPC) highlighted, Facebook's policies are often informally documented and constantly changing. This lack of rigor leads to "privacy surprises"—situations where a user thinks a post is private, but nested tagging rules make it visible to unintended audiences.

The Insight: Marrying RBAC with Dynamic Constraints

The authors identify that standard Role-Based Access Control (RBAC) is insufficient for social networks. In a typical company, roles (like "Manager" or "HR") are static. In a social network, "roles" (like "Friend" or "Friend-of-Friend") depend entirely on the system state—who is friends with whom at that specific moment.

To solve this, they propose SecureUML, which combines:

1. RBAC Architecture: Defines roles and permissions.
2. OCL (Object Constraint Language): Adds the "logic" layer, allowing permissions to depend on dynamic variables like @caller, @self, and specific object attributes.

Methodology: Formalizing the Social Graph

The paper builds a UML data model reflecting the core entities of a social network: Profiles, Timelines, Posts, and Tags.

The readPost Logic

The most complex part of the policy is the visibility of a post. The authors formalize the readPost(@post) method using OCL expressions that check multiple conditions. For example, a user can read a post if:

• They are the owner of the timeline.
• They are the creator of the post (and not blocked).
• The audience is set to 'Friends' and they are in the friends list.
• The "Tagging" Clause: They are tagged in the post, unless they are blocked.

This formalization captures the subtle ways visibility expands; for instance, tagging a user often automatically extends the audience to that user's friends, a nuance often missed by casual users.

Experiments: Solving Privacy Paradoxes

The authors tested their model against four scenarios (S1–S4). A key highlight is Scenario S3:

Alice posts to 'Friends' and tags Bob. Bob then tags Ted. Can Peter (Ted's friend) see the photo in Alice's timeline?

In the 2013 version of Facebook, the answer was Yes (the audience expanded automatically). By 2014, Facebook added a "Friends of those tagged" checkbox. The authors showed that by simply adding a boolean attribute audExt to the Post class and updating the OCL constraint, the model remained robust and accurate across policy versions.

Verification with SMT Solvers

The ultimate power of this approach is Formal Reasoning. By converting the SecureUML/OCL models into first-order logic, the authors used the Z3 SMT solver to prove security properties. They successfully proved that the "Block" function is a "hard" constraint—no matter how many tags or friendship links exist, a blocked user can never bypass the restriction to read a post.

Critical Analysis & Conclusion

Takeaways

• Predictability: Formal models provide a "ground truth" that protects against unintended data exposure.
• Change Management: When a platform changes its UI or policy, a formal model allows developers to run "impact analysis" to see which users will be affected.

Limitations

The current work focuses on a subset of Facebook's features. Extending this to include "Custom Friends Lists," "Restricted Lists," and "Groups" would significantly increase the state space and complexity of the OCL expressions. Furthermore, the model assumes the underlying code follows the formal specification—a "gap" that is always present unless the code is generated directly from the model (Model-Driven Security).

Future Outlook

As regulations like GDPR demand more transparent data processing, using formal languages like SecureUML could become a standard for "Privacy by Design," allowing regulators to audit platforms not just by reading their prose, but by verifying their logic.