Anonymously Sharing Flickr Pictures with Facebook Friends: Privacy-Preserving ReBAC

TL;DR

Maintaining friend groups across multiple platforms (Facebook, LinkedIn, Flickr) is a manual nightmare. This paper presents a solution that allows you to use your Facebook "Close Friends" list to control access to photos on Flickr without Flickr ever knowing your Facebook name and without Facebook knowing which specific photos you are sharing. It bridges the gap between centralized social identity and decentralized resource hosting using advanced cryptography and the OAuth framework.

The Problem: The Social "Lock-In" and Privacy Paradox

In the current Web 2.0 ecosystem, your "social capital"—your list of friends and categorized circles—is trapped inside silos. If Alice wants to share a private Flickr album only with her "Best Friends" group from Facebook, she is stuck:

1. The Manual Burden: She must ask all those friends to join Flickr and recreate the group there.
2. The Privacy Leak: If Flickr uses an OAuth query to check Alice's Facebook friends, Flickr learns exactly who Alice's friends are, revealing sensitive relationship metadata.
3. The Tracking Issue: The Social Network (SN) learns exactly which resources (URLs) Alice is hosting on the external Service Provider (SP).

Methodology: Cryptographic Decoupling

The authors propose a "Privacy-Preserving SNS-based Access Control" mechanism. The core intuition is to let the Social Network act as an Attribute Verifier without letting it become a Resource Tracker.

1. The Group Signature Approach

The most robust method presented uses Group Signatures (where any member can sign on behalf of a group anonymously).

• Owner Token (ot): Alice creates a token containing an encrypted policy and a commitment to the resource.
• Requester Token (rt): Bob (the friend) creates a token proving he is a member of the SNS.
• Linking Token (lt): The SP creates a Zero-Knowledge Proof (ZKP) showing that both tokens refer to the same resource.

The Extract algorithm at the SNS side allows the SNS to see "User A wants to share with User B," but because the resource ID is hidden in a commitment, the SNS never learns what is being shared.

2. The OAuth Implementation

Recognizing the friction of deploying new crypto, the authors also show how to "hack" OAuth 2.0. By using specific scopes (policyEval_owner and policyEval_requester), the SNS can issue opaque strings that serve as temporary pseudonyms, allowing the SP to perform a boolean "Yes/No" check on access without seeing the underlying social graph.

Experimental Insights & Efficiency

Does privacy come at the cost of performance? The authors argue "No."

Using an Elliptic Curve instantiation (Bichsel et al. scheme):

• Owner Token Generation: 9 exponentiations (Fast enough for mobile devices).
• Token Size: Between 2KB and 3KB (Negligible for modern web requests).
• Latency: The group signature method requires fewer round-trips than OAuth (which usually involves multiple HTTP redirects).

Critical Analysis & Conclusion

This paper is a seminal look at Relationship-Based Access Control (ReBAC) across domain boundaries.

The Takeaway: The work successfully solves the "Three-Body Problem" of social sharing: Identity (SNS), Hosting (SP), and Privacy (The User).

Limitations: While the crypto is sound, the OAuth version lacks the "Resource Binding" of the cryptographic version—meaning a malicious SP could potentially "re-play" a friend's access token to check if they have access to other, unrelated policies. This highlights a classic trade-off: the cryptographic method provides mathematical certainty, while the OAuth method provides deployable convenience.

As we move toward a more decentralized web, the principles in this paper—decoupling the authority of a relationship from the enforcement of an access rule—will be foundational for user-centric privacy.

This article is a technical review of "Anonymously sharing Flickr pictures with facebook friends" by Camenisch et al., published in ACM SIGSAC (CCS'13).