Beyond "Friends Only": Formalizing OSN Security with Alloy and the NIST Policy Machine

TL;DR

Managing privacy on Online Social Networks (OSNs) is a nightmare for regular users. This paper tackles the "Misconfiguration Gap"—the distance between what a user thinks they are sharing and what the system actually exposes. By combining the formal verification power of Alloy with the enforcement flexibility of the NIST Policy Machine, the authors provide a roadmap for moving from messy, error-prone social settings to a mathematically verified access control framework.

The "Mental Model" Gap in Social Privacy

Most OSN users treat access control as a simple list of friends. However, OSNs are complex graphs where relationships overlap (e.g., a "Blocked" person might join a "Photography Club" group you belong to). Prior work shows that users consistently fail to anticipate how these overlapping features interact. When a user restricts a friend but allows a group, who wins? This ambiguity leads to "disastrous consequences" in data leakage.

Methodology: The Three-Tiered Approach

1. The Social Entity-Relationship Model

The authors first define the OSN universe through an ER diagram, categorizing entities like Users, Subjects, Objects, and Operations. Crucially, they introduce Relationship Sets like HierRel (Family is a subset of Friends) and MutuallyExclusive (you cannot both "Block" and "Follow" someone).

2. Formal Analysis with Alloy

To find hidden bugs in a user’s policy, the authors translate the social graph into Alloy. Alloy treats policy rules as constraints and uses a SAT-solver to find "Counter Examples."

• The Goal: If a user says "Don't let Bob see my photos," but Bob is in a group that has "View" permissions, Alloy identifies this conflict before the photo is even posted.
• Key Logic: The model enforces irreflexive relationships (you can't be your own friend) and transitive closures for hierarchies.

3. Enforcement via NIST Policy Machine (PM)

While Alloy finds errors, the Policy Machine enforces the rules. The authors map OSN relationships to PM Containers. For example:

• Contained-in Relation: If a user is in the "Family" container, they are automatically granted permissions of the "Friends" container.
• Disjoint Containers: If "Friends" and "Blocks" are disjoint, the system prevents a user from existing in both simultaneously.

Experimental Insight: Catching the "Smartlist" Leak

The study highlights a fascinating misconfiguration: Interest Group Updates.

• Scenario: User A restricts User B. User A then shares a post to an "Interest Group."
• The Bug: If User B subsequently joins that Interest Group, they might gain access to User A's post despite being restricted.

The Alloy analyzer detects this by comparing the state "before" and "after" the group update, alerting the user that a restricted individual now has access.

Critical Insight & Conclusion

The true value of this work is the shift from Relationship-Based Access Control (ReBAC) to Attribute-Based Access Control (ABAC). By treating a relationship (like "Friend") as an attribute within a container-based system (the Policy Machine), we gain a more "elegant" administrative control.

Comparison & Future Outlook

Takeaway: As OSNs evolve into "Metaverse" style environments with hundreds of varying attributes (location, device, history), manual privacy settings are dead. Formal frameworks like the one proposed here are the only way to ensure user intent actually matches system reality.

Future Work: The authors aim to integrate Spatio-temporal constraints—essentially asking: "Does my privacy policy change if I'm at work vs. at home?"