Source-linked AI summary
DECENT: A Decentralized Architecture for Enforcing Privacy in Online Social Networks
Sonia Jahid, Shirin Nilizadeh, Prateek Mittal, Nikita Borisov, Apu Kapadia
TL;DR
Centralized OSNs raise privacy concerns, while existing alternatives leave gaps in data management and relationship privacy. DECENT combines object-level access control and cryptographic protections with DHT storage; simulation and PlanetLab experiments report moderate overhead and feasibility.
Problem
Centralized OSNs limit user control and fine-grained access policies, while alternative designs leave data-management or relationship-privacy gaps.
Source: §1 · p. 1Method
DECENT stores encrypted data objects in a DHT and integrates object-oriented management, cryptographic confidentiality and integrity, and flexible policies with fast revocation.
Source: §1 · p. 1, §3 · p. 2, §3.2 · p. 3Results
Takeaways & Limitations
The prototype demonstrates that existing security primitives can support a privacy-preserving alternative to centralized OSNs within the evaluated scope.
Source: §1 · p. 1Further performance improvement through optimized cryptography, caching, and replication remains future work.
Source: §6 · p. 7
Abstract
from arXiv · showhide
A multitude of privacy breaches, both accidental and malicious, have prompted users to distrust centralized providers of online social networks (OSNs) and investigate decentralized solutions. We examine the design of a fully decentralized (peer-to-peer) OSN, with a special focus on privacy and security. In particular, we wish to protect the confidentiality, integrity, and availability of user content and the privacy of user relationships. We propose DECENT, an architecture for OSNs that uses a distributed hash table to store user data, and features cryptographic protections for confidentiality and integrity, as well as support for flexible attribute policies and fast revocation. DECENT ensures that neither data nor social relationships are visible to unauthorized users and provides availability through replication and authentication of updates. We evaluate DECENT through simulation and experiments on the PlanetLab network and show that DECENT is able to replicate the main functionality of current centralized OSNs with manageable overhead.
1. Introduction
The introduction motivates decentralized OSNs by privacy and access-control shortcomings in centralized and alternative designs. DECENT integrates flexible data management, cryptographic protections, and DHT-based availability, with a prototype evaluated in simulation and on PlanetLab.
1. Introduction
- Centralized OSNs expose user data to providers and offer limited fine-grained access control, while alternative designs leave data-management and relationship-privacy gaps.Some decentralized proposals store data with owners or trusted contacts; DECENT evaluates wall and newsfeed functionality in a prototype.Source: §1 · p. 1
- DECENT combines object-oriented data management, fine-grained policies and efficient revocation, and DHT mechanisms for confidentiality, integrity, and availability.The paper presents this integration as a design contribution rather than a new security primitive.Source: §1 · p. 1
- Simulation and PlanetLab experiments on the prototype show moderate overhead and support the feasibility of privacy-preserving decentralized OSNs.The prototype covers wall and newsfeed functionality and uses FreePastry simulation and a Kademlia implementation on PlanetLab.Source: §1 · p. 1
2. Requirements and Properties
DECENT models social content as linked objects with separately assigned permissions. Its requirements cover content security, owner-defined access policies, relationship privacy, and resilience to malicious participants under a bounded threat model.
2.1. Functional Model
- Profiles and other containers reference content objects, allowing permissions to be assigned per object and comments to have stricter access than their content.A single object may be referenced by multiple parent objects, so the hierarchy need not be a tree.Source: §2.1 · p. 2
2.2. Security Requirements
- Content must be readable only by explicitly authorized users, and integrity must let users verify that friends’ posted content is authentic despite untrusted storage nodes.Source: §2.2 · p. 2
- Content should remain available until owner deletion despite malicious destruction, readers should retrieve its latest version, and owners alone authorize policy changes.Source: §2.2 · p. 2
- Policies should express conjunctions or disjunctions of contact attributes and relationship degree, while third parties without a relationship to the owner should not see user relationships.Source: §2.2 · p. 2
2.3. Threat Model
- The threat model allows Byzantine malicious or compromised nodes and up to 25% malicious participants, assumes Sybil defenses, and excludes routing-based attacks from focus.The stated 25% bound reflects that existing mechanisms cannot securely route in DHTs beyond that threshold.Source: §2.3 · p. 2
3. System Architecture
DECENT separates encrypted owner-created objects, cryptographic mechanisms, and DHT storage behind defined interfaces, while using object policies to control access. Its architecture combines privacy and integrity protections with replicated, authenticated DHT operations and proxy-based revocation.
3. System Architecture
- DECENT modularly combines encrypted data objects, cryptographic mechanisms, and DHT storage to provide a decentralized OSN architecture.Its components interact through well-defined interfaces, allowing different DHTs or cryptographic schemes to be used.Source: §3 · p. 2
3.1. Access Policies
- Objects use attribute- or identity-based read, write, and append policies, enforced through cryptography and specialized DHT operations.Read policies govern decryption; write policies govern modification or deletion; append policies govern comments and annotations.Source: §3.1 · pp. 2–3
3.2. Cryptographic Protection
- Attribute-based encryption supports access policies over contact attributes; placing the encrypted symmetric key in each reference hides policies from storage nodes and allows different read policies per reference.A single object may be reached through references with different policies, exposing it to different contact subsets.Source: §3.2 · p. 3
- EASiER supports immediate attribute revocation through a minimally trusted proxy, while proposed threshold sharing distributes proxy functionality and delegation supports friend-of-a-friend attributes.A delegated decryption requires both Alice’s and Bob’s proxies, so revocation by either can make decryption fail.Source: §3.2 · p. 3
- DECENT cannot architecturally prevent Bob from re-sharing data he can access; the passage suggests warning him as a possible mitigation.It states that preventing such re-sharing would require DRM.Source: §3.2 · p. 3
3.3. Distributed Hash Table
- DHT replication addresses node churn and malicious attacks, while signed version numbers let users select the freshest returned replica.The number of replicas must be tuned to network churn patterns, which the paper leaves for future evaluation.Source: §3.3 · p. 4
- Per-object write-authentication keys let storage nodes reject unauthorized writes or deletions, preserving an object if at least one replica remains honest.Separate keys for each object help prevent storage nodes from linking objects to their owner.Source: §3.3 · p. 4
3.4. Example
- In the example, Alice’s root links her profile and wall; status references carry encrypted keys, and comments require authorized appends and both status and comment read policies.A reader retrieves the object from the DHT and verifies Alice’s signature; comment references are checked against the status’s append policy.Source: §3.4 · pp. 4–5
4. Implementation and Evaluation
DECENT’s prototype was evaluated through simulation and PlanetLab experiments on wall viewing, newsfeeds, and posting or commenting. Viewing times varied by workload, while progressive loading could show recent wall messages before the full wall finished loading.
4.1. Simulation
- Viewing an own wall with 20 statuses, posts, and comments took 90 seconds, but recent messages loaded within the first few seconds.Progressive display lets older messages be fetched while the user reads recent ones.Source: §4.1 · p. 5
- A 40-feed simulation newsfeed took around 215 seconds to construct and view; current OSNs generally show 20–30 posts at a time.Feed blocks and pre-fetching updates while users are offline were proposed as performance improvements for future evaluation.Source: §4.1 · p. 5
- Posting or commenting averaged 3.94 seconds, and users could continue their OSN activities while the update was performed.The user signs the post or comment reference with the parent object's append-policy signature key.Source: §4.1 · p. 5
- Simulation wall viewing took about 60 seconds with 10 statuses, posts, and comments, and 120 seconds with 20; a 20-peer newsfeed took 109 seconds.The simulation used 10,000 nodes.Source: §4.1 · p. 5, Figure 2 · p. 6
4.2. Experiments on PlanetLab
- 37.3 seconds (95% confidence interval [34.4, 40.1] s) were needed to construct and view a PlanetLab newsfeed with 11 feeds.The measured time closely resembled the simulation results.Source: §4.2 · pp. 5–6
- About 168 seconds were needed to view a PlanetLab wall with 10 statuses, posts, and comments.The PlanetLab experiments used 15 nodes; node failures left some walls unavailable or only partially retrieved.Source: §4.2 · p. 5, Figure 3 · p. 6
5. Related Work
Prior decentralized OSN work explored privacy through cryptography, architectural changes, or decentralizing the provider. DECENT’s related-work comparison emphasizes fine-grained access, revocation, relationship privacy, and wall interactions.
5. Related Work
- Prior OSN privacy projects used cryptography, architectural changes, or provider decentralization, including Diaspora, PeerSon, Safebook, and LotusNet.Diaspora runs on users’ personal web servers without encryption, while LotusNet treats distributed storage as trusted and does not encrypt data.Source: §5 · p. 6
- PeerSon [12] and Safebook [16] lack the fine-grained policies of ABE-based access control, and key-revocation overhead affects performance across the compared schemes.Safebook’s Matryoshka overlay relies on existing hop-by-hop trust for end-to-end privacy.Source: §5 · p. 6
- Compared with Persona, DECENT supports fine-grained revocable access, protects social contacts and privacy policies from storage nodes, and provides wall commenting.Persona’s storage service can learn social contacts, and its wall protocol lacks commenting.Source: §5 · p. 6
6. Conclusion and Future Work
The paper presents DECENT as a decentralized social-network design combining cryptographic protections with a DHT. Its preliminary prototype experiments support feasibility, while added features and performance and resilience improvements remain future work.
6. Conclusion and Future Work
- DECENT combines cryptographic mechanisms for confidentiality and integrity with a DHT for availability in decentralized social networks.The design emphasizes security and privacy.Source: §6 · p. 6
- Simulation and PlanetLab experiments with a preliminary prototype support the feasibility of a DHT-based privacy-enhanced OSN focused on confidentiality and integrity.Source: §6 · p. 6
- Future work includes adding features and improving performance and resilience through optimized cryptographic techniques, caching, and replication.Source: §6 · pp. 6–7