CReDiC: Securing the Ripple Effect in Decentralized Social Networks

TL;DR

In decentralized social networks (DOSNs) like Diaspora*, resharing is often an "all-or-nothing" gamble. This paper introduces a Relationship-Based Access Control (ReBAC) mechanism that allows authors to control how their messages spread through chains of "friends of friends." By calculating trust values across the delivery path and using decentralized controllers, the system enforces privacy with a performance hit of less than 5%.

The "Resharing" Dilemma in Decentralized Networks

In a centralized network like Facebook, the platform knows every link in the social graph. In a Decentralized Online Social Network (DOSN), your profile is stored on one "pod" (server), and your friends might be on ten others.

Current DOSNs struggle with a specific pain point: Controlled Resharing. If Alice shares a secret with Bob, she might trust Bob to see it, but does she trust Bob's friends? Existing systems either block Bob from resharing entirely (killing social growth) or let him reshare to anyone (killing privacy). This paper argues that access should be a function of the path the information took.

Methodology: Trust as a Chain of Probability

The core insight is mapping social relationships to a mathematical Reshare Path.

1. Scalar Trust: Users assign a value $[0,1]$ to their categories (e.g., "Close Friends" = 0.9, "Acquaintances" = 0.3).
2. Trust Concatenation: When Bob reshares Alice's message to Charlie, the system calculates the "Path Trust" ($PT$): $PT=extTrust(extAliceoextBob)imesextTrust(extBoboextCharlie)$
3. Sensitivity Threshold: Every message has a sensitivity $s$. Resharing is only allowed if the Path Trust exceeds a coefficient derived from $s$.

Decentralized Orchestration

To avoid a "Single Point of Failure," the authors developed a 4-phase coordination protocol using CliSeAu (a tool for distributed policy enforcement).

• Phase 1-2: Identify the author and the original sensitivity.
• Phase 3: Compute the product of trust values by hopping between the controllers of the providers involved in the path.
• Phase 4: Make a final "Allow/Deny" decision.

Experimental Results: Performance without Friction

The authors implemented this as CReDiC for the Diaspora* network. A common concern with decentralized coordination is latency (the time it takes for servers to "talk" to each other).

The results were surprisingly lean:

• Intra-pod resharing: Overhead of ~3.9ms (1.34% increase).
• Inter-pod resharing: Overhead of ~12.5ms (4.44% increase).

This shows that the ReBAC check is fast enough to be imperceptible to the end user.

Critical Insight: Why This Matters

The "Trust Multiplication" approach has a natural physical intuition: trust decays as it moves further from the source.

However, the paper acknowledges a key limitation: Out-of-band communication. No technical access control can stop Bob from taking a screenshot of Alice's post and emailing it. Therefore, ReBAC is a tool for policy compliance within the ecosystem, not a silver bullet against malicious leaks.

Conclusion

CReDiC provides a blueprint for how we can build social networks that are both broad (allowing information to spread) and safe (strictly limiting that spread to trusted circles). It maintains the spirit of decentralization by ensuring no single provider needs to know the entire global social graph to make an authorization decision.