Preserving User Privacy: Shifting from Data Exposure to Local Consumption in OSNs
Preserving user privacy from third-party applications in online social networks
The paper proposes a novel access control framework for Online Social Networks (OSNs) to protect user data from Third-Party Applications (TPAs). It introduces a hybrid architecture that splits TPAs into internal (trusted) and external (untrusted) components, allowing the processing of sensitive data within the OSN's security boundary while achieving State-of-the-Art (SOTA) fine-grained privacy control.
TL;DR
The privacy crisis in Online Social Networks (OSNs) often stems from a fundamental design flaw: Third-Party Applications (TPAs) must exfiltrate user data to external servers to provide features. This paper introduces an architectural paradigm shift that splits applications into Internal and External components. By processing sensitive data inside the OSN and only sending non-sensitive results outside, users can enjoy social apps without surrendering their digital identities.
Problem & Motivation: The "All-or-Nothing" Trap
In the current OSN ecosystem (Facebook, OpenSocial, etc.), privacy is treated as a binary choice. If you want to play a game or use a productivity tool, you must click "Allow" on a massive list of permissions.
The authors identify three critical pain points:
- Over-privilege: 91% of top apps access data they don't actually need.
- Loss of Control: Once data leaves the OSN server for a TPA server, it can be sold or leaked without oversight.
- Collateral Exposure: Your friends can "give away" your data to apps they install, even if you never consented.
The motivation here is to move away from "Proxy-based sanitization" (which often breaks apps) towards a Trusted Component model.
Methodology: The Split-Component Architecture
The core innovation is the decomposition of TPAs. Instead of an app running entirely on a developer's server, it is split into:
- Internal Components: Hosted by the OSN. These are "sandboxed" modules that can see raw private data but are physically restricted from sending it over the internet.
- External Components: Hosted by the TPA developer. These handle heavy computation or UI but only receive "privacy-nonsensitive" data or simple system call triggers.
Architectural Overview
The framework categorizes internal modules into four types (M1 to M4) based on who provides them (OSN vs. TPA) and how they communicate.
Physical Intuition: Think of the OSN as a secure vault. Previously, you gave the app a copy of your key. In this new framework, the app sends a "worker" (Internal Component) into the vault to count your money, and the worker only exits to tell the app the total count, not the serial numbers of the bills.
Relationship-Based Access Control (ReBAC)
To govern this, the paper uses an expressive policy language:
[action, target, (start, path_rule), ModuleType]
This allows for high-precision rules. For example:
- Alice allows an app she installed to see her birthday via Internal Modules (M1/M2).
- Alice forbids the External Component of the same app from ever seeing that same data.
This effectively uses the social graph topology to define trust boundaries.
Experiments & Case Studies
The paper validates the approach through functional scenarios like "Application Notifications."
By utilizing Type M1/M2 modules, an app can send a notification to a user's friends (using the OSN's internal social graph) without the app's external server ever knowing the names or IDs of those friends. This achieves the "Principle of Least Privilege" while maintaining 100% of the app's functionality.
Critical Analysis & Conclusion
Takeaway
The shift from "Sanitizing Data" to "Isolating Computation" is the most robust way to handle TPA privacy. This paper laid the groundwork for modern concepts like Edge Computing and Zero-Knowledge processing in social contexts.
Limitations
- Covert Channels: While the framework blocks overt data transmission, malicious internal modules could theoretically leak data through side channels (though the authors consider this out of scope).
- Incentives: For this to work, OSN providers (like Meta) must be willing to host TPA code internally, which increases their infrastructure costs.
Future Prospect
With the rise of Web3 and decentralized Social Networks, this "Split-Architecture" is more relevant than ever. Integrating these policies with Smart Contracts or Zero-Knowledge Proofs could automate the "Reference Monitor" (RM) described in this paper, removing the need to trust a central OSN provider entirely.