Beyond Access Control: Enforcing Data Usage Privacy in Social Networks

5675_Distributed data usage control for web applications a social network implementation.

Summary
Problem
Method
Results
Takeaways
Abstract

This paper introduces a distributed usage control framework for Web-Based Social Networks (WBSN) aimed at controlling data actions (print, copy, save) after access is granted. The core implementation consists of SCUTA, a trust-aware social platform, and BRUCE, a Mozilla Firefox extension that serves as a client-side Policy Enforcement Point (PEP).

TL;DR

Granting someone "Friend" status on a social network shouldn't mean giving them a permanent license to download and redistribute your photos. This paper presents a framework that extends security into the post-access phase, using a Firefox extension called BRUCE to prevent unauthorized printing, copying, or saving of sensitive content based on social trust levels.

Context: The Gap in Social Media Privacy

In the current Web 2.0 landscape, privacy is binary: you either see the content or you don't. Once Bob has access to Alice's profile, the browser provides him with all the tools to leak that data—Ctrl+C, "Save Image As," or simple printing. Current countermeasures, such as overriding the right-click menu with JavaScript, are "security theater" that can be bypassed by any user who knows how to open the developer console.

The authors argue that we need Distributed Usage Control. The goal is for the data owner (Alice) to define policies that stick to her data even after it has left her server and landed in Bob's browser.

Methodology: The SCUTA/BRUCE Architecture

The framework operates through three main pillars:

  1. SCUTA (The Server): A modified social network that calculates a "Permission Class" by multiplying a user's Trust Value (0.0–1.0) with the data's Sensitivity (0.0–1.0).
  2. BRUCE (The Client): A Mozilla Firefox extension that acts as a gatekeeper. It listens for internal browser commands and pauses them until it receives verification.
  3. The PDP (Policy Decision Point): A remote engine that stores Event-Condition-Action (ECA) rules and tells the client whether to Allow or Inhibit an action.

How it Works

When Alice marks a photo as "High Sensitivity," the server wraps it in a specific HTML class (e.g., class="lowPermission"). It then sends a policy to Bob's browser via custom HTTP headers (x-policy_url). If Bob tries to copy the image, BRUCE intercepts the cmd_copy event, checks the policy via the PDP, and kills the process before the clipboard is ever updated.

Architecture of BRUCE Figure 1: The BRUCE Architecture, showing the flow from event interception to Policy Decision.

Security Analysis: The "Honest Client" Problem

The authors perform a rigorous evaluation using Attack Trees, which highlights the inherent fragility of client-side enforcement.

  • The Man-in-the-Middle: Since policies are sent over HTTP headers, an attacker can simply strip the x-set_scope header, making the browser think the page is unprotected.
  • Browser Integrity: If a user installs a second, malicious extension, it could theoretically "un-hook" BRUCE's listeners or modify the DOM to remove the permission classes.
  • The Layer Problem: Even if the browser is secure, the data is still in the system cache or visible on the screen. The user can take a screenshot (OS-level) or look in the temporary files (File System-level).

Attack Tree for BRUCE Figure 2: Attack tree showing various ways to circumvent the BRUCE extension.

Critical Insight: The Future of Data Centricity

The most striking takeaway from this work is the transition toward Data-Centric Security. The authors admit that browser-level control is only one piece of the puzzle. For usage control to be truly effective, it must be "cross-layer."

When BRUCE detects a protected image being cached to the hard drive, it must communicate with the Operating System's usage control mechanism to ensure that file remains encrypted or unreadable by other applications. This requires a unified "Data Flow Tracking" system that spans from the network packet to the pixels on the screen.

Conclusion

While the implementation is a prototype (limited to native HTML/images and specific to Firefox), it sets the stage for a more nuanced internet where privacy isn't just about "who can see," but "what can be done." The research underscores that the next frontier of privacy isn't better encryption, but better enforcement of trust in distributed environments.

Limitations to Note:

  • Does not currently handle Non-native data (PDF, Flash).
  • Relies on the assumption that the user won't manually modify the extension's JavaScript source code.
  • Currently handles single-user pages better than multi-user search results.

Find Similar Papers

Try Our Examples

  • Examine recent literature on "Client-Side Usage Control" that utilizes Trusted Execution Environments (TEEs) or Intel SGX to address the malicious client/extension problem identified in this paper.
  • Which 2004 paper by Park and Sandhu defined the "UCON ABC" usage control model, and how does this implementation's ECA-based logic map to those theoretical components?
  • Investigate how modern data loss prevention (DLP) systems for web browsers have evolved to handle non-native data types like WebAssembly or PDF, which were listed as limitations in the BRUCE framework.
Contents
Beyond Access Control: Enforcing Data Usage Privacy in Social Networks
1. TL;DR
2. Context: The Gap in Social Media Privacy
3. Methodology: The SCUTA/BRUCE Architecture
3.1. How it Works
4. Security Analysis: The "Honest Client" Problem
5. Critical Insight: The Future of Data Centricity
6. Conclusion