a survey on decentralized online social networks

1

3

4

5

6 Q1

78 Q29

10

1 2

1314151617

1819 Q4202122

2 3

3738

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

Q3

Computer Networks xxx (2014) xxx–xxx

COMPNW 5404 No. of Pages 16, Model 3G

16 October 2014

Q1

Contents lists available at ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/ locate/comnet

A survey on decentralized Online Social Networks

http://dx.doi.org/10.1016/j.comnet.2014.10.0051389-1286/� 2014 Published by Elsevier B.V.

⇑ Corresponding author.1 http://allfacebook.de/userdata/ – accessed on 16th of January 2014.

Please cite this article in press as: T. Paul et al., A survey on decentralized Online Social Networks, Comput. Netw. (2014), http://dx.10.1016/j.comnet.2014.10.005

Thomas Paul a,⇑, Antonino Famulari b, Thorsten Strufe c

a Technische Universität Darmstadt, Hochschulstrasse 10, 64380 Darmstadt, Germanyb Télécom ParisTech, INFRES, 23, Avenue d’Italie, 75013 Paris, Francec Technische Universität Dresden, Nöthnitzer Straße 46, 01187 Dresden, Germany

24252627282930313233

a r t i c l e i n f o

Article history:Received 20 January 2014Received in revised form 15 September 2014Accepted 1 October 2014Available online xxxx

Keywords:Online Social Network (OSN)Distributed Online Social Network (DOSN)Privacy

3435

a b s t r a c t

Because of growing popularity of Online Social Networks (OSNs) and huge amount of sen-sitive shared data, preserving privacy is becoming a major issue for OSN users. While mostOSNs rely on a centralized architecture, with an omnipotent Service Provider, severaldecentralized architectures have recently been proposed for decentralized OSNs (DOSNs).In this work, we present a survey of existing proposals. We propose a classification of pre-vious work under two dimensions: (i) types of approaches with respect to resource provi-sioning devices and (ii) adopted strategies for three main technical issues for DOSN(decentralizing storage of content, access control and interaction/signaling). We pointout advantages and limitations of each approach and conclude with a discussion on theimpact of DOSNs on users, OSN providers and other stakeholders.

� 2014 Published by Elsevier B.V.

36

57
1. Introduction legitimate profit interests lead to strong incentives for 58
59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

Online Social Networks (OSNs) are one of the most pop-ular services on the Web with more than one billion users.1

Yet, OSNs are not just tremendously popular; they have alsochanged the way we interact with the Web and itsresources: OSNs allow non-expert users to create and main-tain a personal space in the Web in a simple way. OSNsevolved in time, providing several communications andsharing facilities which cause users to share huge quantitiesof personal information [22] over them.

Nevertheless, users of today’s popular OSNs sufferundesired side effects resulting from a centralized archi-tecture of OSNs in which one provider has the power thatis accompanied with being the operator of the system.These side effects include: the necessity for a high degreeof trust in the OSN provider, censorship issues and privacyconcerns.

Economic pressure to earn money due to provider-sideinfrastructure and maintenance costs and the provider’s

77

78

79

OSN providers to monetize user data far beyond the user’ssharing interests [20]. But users need to trust the latter notto misuse the power, accompanied with being the operatorof the system, as well as to be able to protect the systemagainst both attackers from outside and from inside theprovider’s organization itself. The existence of a powerfulsystem operator combined with monetization incentivescause privacy concerns [27]. Furthermore, different typesof censorship occur in today’s OSNs: the content-specificcensorship with respect to different rules and traditionsin different countries [1,2] as well as person-specific cen-sorship which means disallowing subsets of the populationto access the network (e.g. in Syria today [3]).

However, the importance of OSNs for the daily inter-person communication puts the OSN providers in a posi-tion of being gate keepers to parts of the social life of theirusers. Due to this dependency, users strongly tend toaccept the mentioned side effects and even disadvanta-geous terms of usage, since the OSN providers may excludeusers from the OSNs and subsequently from parts of theirsocial contacts. Authors of decentralized OSN (DOSN)approaches aim to abolish OSN providers and the

doi.org/

http://dx.doi.org/10.1016/j.comnet.2014.10.005

http://allfacebook.de/userdata/


http://www.sciencedirect.com/science/journal/13891286

http://www.elsevier.com/locate/comnet



80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

2 T. PaulQ1 et al. / Computer Networks xxx (2014) xxx–xxx


16 October 2014

Q1

side-effects of centralized OSNs by creating decentralizedsystems, providing the social networking functionality.

Approaches for encrypting content in centralized OSNs(e.g. [27]) may mitigate content censorship and communi-cation confidentiality concerns but they still allow the OSNprovider to observe communication patterns. Individualscan still be excluded from the system to conduct censor-ship. Those encryption approaches also raise the questionwhether the business models of today’s OSNs still workand allow the providers to make sufficient infrastructureavailable. We thus argue that decentralization is the bestavailable concept to address the trust, the privacy andthe censorship issues.

Many kinds of DOSNs have been proposed by severalauthors. Nevertheless, the idea of distributing OSNs hasnot been widely adopted. Beside Diaspora,2 none of theDOSNs has a denotative user basis. In contrast to the authorsof many DOSNs, Narayanan et al. doubt in [34] that decen-tralizing OSNs is a feasible way to build social networkingservices. We argue that distributing OSNs is a worthwhileidea and aim to help the DOSN community with this surveyby elaborating and evaluating what has been suggested inthe field of DOSN.

In the remainder of this survey, we define the terms,which are elementary for this article in Section 2. We stateour requirements and adversary models (Section 3) andintroduce a DOSN architecture model to explain the designspace (Section 4) as well as the design decisions that haveto be made in case of creating DOSN architectures (Section5). These design decisions determine the properties ofDOSNs. Thus, they are the basis for our classification inTable 1. In Section 6, we discuss both: the consequencescaused by the design decisions as well as the propertiesof DOSN classes (with respect to our classification). Fur-thermore we list all approaches which fit in the shape ofour DOSN definition, discuss the features of the differentDOSN approaches and provide a publication time line toilluminate the publication history (Section 7). Several ideasto improve aspects in the field DOSNs have been publishedwithout suggesting a complete new architecture. Since weconsider them to be important contributions, we introducea selection of DOSN related approaches in Section 9.Finally, we elaborate the impact of decentralization on dif-ferent OSN affiliates and summarize and conclude ourarticle.

178

179

180

181

182

183

184

185

186

187

188

189

2. Definitions

This Section defines specific terms used in this article:Section 2.1 contains elementary terms, Section 2.2 definesdifferent types of decentralization as well as terms that areclosely related to decentralization and Section 2.3 specifiesDOSN components.

2.1. Elementary terms

We use the term Personal identifiable information (PII) asit has been introduced by the Data Protection Directive 95/

190

1912 https://joindiaspora.com/ – accessed on 14th of January 2014.

Please cite this article in press as: T. Paul et al., A survey on decentralized10.1016/j.comnet.2014.10.005

46/EC of the European Parliament. PII is ‘‘any informationrelating to a [. . .] natural person [. . .] who can be identified,directly or indirectly, in particular by reference [. . .] to oneor more factors specific to his physical, physiological, men-tal, economic, cultural, or social identity’’. PII can consist ofcontent, e.g. pictures and messages, as well as all types ofincidental data which can be derived from e.g. technicalproperties (e.g. size) of content or communicationparameters.

Authorization is a mechanism to decide about legitimi-zation based on previously defined rules. Access controldenotes the action to allow legitimized subjects to accesscontent and to prohibit unauthorized access. According to‘‘privacy as control’’ in [16], privacy in our context meansthe effectiveness of users to be able to restrict access toinformation that the user is responsible for (as a producerof the message). The effectiveness can be affected by tech-nical and social (e.g. social engineering) interferences.

An Online Social Network (OSN) in this article is ‘‘anonline platform that (1) provides services for a user tobuild a public profile and to explicitly declare the connec-tion between his or her profile with those of the otherusers; (2) enables a user to share information and contentwith the chosen users or public’’ [37].

Since each OSN provides different functionality, wedecided to distinguish basic functionality which needs tobe part of the system to be considered being an OSN andthe extended functionality, which is not qualifying butextends the service in a specific way.

Derived from the definition of OSN, basic functionalityconsists of:

� Profile management: creating, maintaining and deletingof user profiles, which subsequently includes authoriza-tion mechanisms for profile attributes.� Relationship handling: establishing and removing new

relationship declarations.� Interaction: direct interactions (internal messaging sys-

tem – 1:1) and indirect interactions by sharing content(1:n).

The extended functionality, we define for this article, is aset of features which some of today’s OSNs provide. Thereason for mentioning them in this definition is that weconsider these to be important pieces, contributing to theattractiveness and popularity of the OSN platforms. Wetake the following into account:

� An API, allowing third party applications to run on theOSN platform.� A search function to find other users of the OSN.� A recommender system that recommends users to

become friends or content to be consumed.� A social network connector, bridging different social

networks.

2.2. OSN decentralization definitions

Decentralization has more than one dimension in thefield of OSN. We distinguish between technicaldecentralization (resource distribution) which means that

Online Social Networks, Comput. Netw. (2014), http://dx.doi.org/

http://https://joindiaspora.com/



192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

Table 1DOSN approaches; (D = distributed, FD = fully distributed, BE = broadcast encryption, OOB = out of band).

Arch. Ref Degree Storage AC Interact Mech. Comments

Peers Server ACLs Encr. Centr. Dec.

P2P-OSN PeerSoN FD Previousdownload

– – – PKI – Direct + DHT Support for direct interactions (also with noInternet access)

Safebook FD Trustedfriends

– – PKI – DHT Anonymity of interactions via encryptionand recursive hop-by-hop routing

LifeSocial.KOM

FD DHT – – BE – Plugins Interactions based on external applications(plugins)

LotusNet FD DHT – – PKI – DHT Based on LikirDECENT FD Random

nodes in aDHT

– – ABE – DHT Social network functionality on top ofEASIER

Cachet FD Randomnodes in aDHT

– – ABE – DHT Performance improvement of DECENT

F-OSN SoNet FD – Active Servers OOB orSMP

– XMPP XMPP-like architecture/social graphobfuscation

Mantle FD – Passive – OOB – Pub/submodel

Group encryption on any storage, pub/subfor interactions

PrPl FD – Active Cloudbuttler

Undef. – Plugins Cloud buttler either at home or in the cloud/own language: SocialLite

Diaspora FD – Active Hostingnodes

– – Hostingnodes

Trusted social hubs, hosting several userpods each

[Anderson] D – Active – PKI – Pub/sub Multi-layer clients with sandbox for externalapplications

Hybrid Vis-a-Vis FD – Passive Userpod

– – DHT P2P substrate, data stored in user pods onpersonal devices/cloud services

[Kryczka] D Social graph,locality

Active Hostingnode

– Centralindex

– Centralized OSN extended with P2P contentstorage

[Raji] D – Active – BE – Pub/sub Private data on personal storage, rest at OSNprovider

Polaris FD – Passive Userhome

– – Ext.apps + direct

Storage on phones or servers, NAT traversalnecessary

Confidant D Trustedfriends

– – OOB Extern.platform

– Storage on trusted servers, existing OSN isused for signaling (notification)

Vegas FD – Passive – PKI – Direct P2P/reliable storage

T. PaulQ1 et al. / Computer Networks xxx (2014) xxx–xxx 3


16 October 2014

Q1

parts of the system run on different machines, at differentparts of the network and authorial decentralization whichmeans distinct and independent authorities run and main-tain technical resources.

Since today’s OSN have a huge number of users, store ahuge amount of data and cause a huge amount of networktraffic, they cannot rely on a single machine at a singleplace in the web. Thus, all OSNs with a certain number ofusers are technically distributed. Since in Facebook, Goo-gle+ and related OSNs one single entity (e.g. company)has the omnipotent power to decide about what is allowedon their OSN platform, we define them to be centralized forthe rest of the paper.

To be considered as a Distributed Online Social Network(DOSN), a communication system needs to fulfill the twocriteria: to provide the core functionality, defined above,and at least one core functionality must not rely on cen-tralized infrastructure. A DOSN is considered fully decen-tralized if this holds for all basic functions.

Abolishing the social network provider along with itsinfrastructure and data centers raises the question howto organize resource provision. Authors of DOSNapproaches offer different answers: decentralization ofOSN can be achieved using Peer-to-Peer (P2P) technology


or dedicated servers which work together by processingfederation protocols. A mixture of both has been suggestedas well.

For the rest of the article, we thus define P2P-OSNs to beDOSNs that leverage P2P technology to provide the basicfunctionality, F-OSNs to be DOSNs that rely on a client–ser-ver infrastructure which is owned and maintained by dif-ferent authorities and Hybrid DOSNs to be DOSNs thatrely on a mixture of P2P and client–server infrastructurefor different functionalities.

Unreliable resources may cause negative effects on theperformance of DOSN. Unavailable storage nodes canpotentially be an obstacle for users to access profile dataof other users. Thus, the availability of the user data (givenas a fraction or percentage of time a data item is available),which is called profile availability in the remainder of thisarticle, is an important quality criterion for DOSN. In con-trast, the service availability means the fraction of time,the social networking service is available to the user.

The issue of profile availability is a particular concern inP2P systems where a set of (unreliable) equal nodes arecommunicating directly without the necessity ofserver-based message distribution. Participating nodes joinand leave the network regularly depending on whether the




240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299300

301

302

303

304

305

306

307

308309

310

311

312

313

314

315

316317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349



16 October 2014

Q1

user uses the service or not. We call this effect Churn [50].It represents the online behavior of nodes in P2P DOSN inthe remainder of this article.

2.3. DOSN components

Components of DOSNs are briefly defined below forlater use within this article:

User: person or organization owning an iden-tifier and a user profile within the OSN.

User profile: digital representation of a user in theOSN, containing all user-owned dataitems.

User handle: unique identifier for every user beingpart of the OSN system.

Content: Data item which is stored or sharedwithin the OSN.

Connection: declared affiliation or acquaintancebetween users (e.g. friendships).

Node: network device, used by users to con-nect to the OSN.

Server: network device, which reliably supportsservice provision.

3. Requirements and adversary models

In this Section, we discuss the requirements that are ourbenchmark to evaluate DOSNs and introduce the adversarymodels that are later used to discuss the security of DOSNs.

3.1. Requirements

In the remainder of the paper we present and discussdifferent DOSN approaches, but none of them has a deploy-ment with a reasonable user base and the full set of func-tionality compared to today’s most popular OSN, Facebook.We consider the non-academic approach, Diaspora, withabout 400,000 users3 to be the most successful DOSN. It stillcomes without a recommender system for friends and con-tent and without a system-wide content and profile discov-ery mechanism.

Elaborating success determinants of DOSN is out of thescope of this article, but according to [34], we assume thatit is a necessary success-precondition for DOSN toimplement attractive functionality in a usable way. Subse-quently, we assume that users do not completely trusttheir OSN providers not to misuse private data [19], butthat they do not want to abdicate benefit of OSN function-ality. Hence, DOSN need to become as usable and as usefulas their centralized counterparts in addition to respectuser’s privacy to become successful competitors.

In our discussion we thus use Facebook as a baseline forthe Quality of Service (QoS). Since we do not have access toimplementations of all proposed DOSN systems (themajority of approaches are scientific and thus implementa-tions may even not exist), we discuss the approaches sub-sequently represented by the set of functionality and

350

3513 https://diasp.eu/stats.html.


performance properties of the proposed DOSN. Further-more, censorship resistance, security issues and economi-cal issues are discussed in the remainder of this article.We thus assume that DOSN need to provide a comparablelevel (compared to centralized OSN) of Service Quality inorder to be considered as an alternative with respect to:

1. System performance� message transfer and profile update delays.

2. Privacy of content and interactions� confidentiality and integrity of communication;� user authentication and access control;� accountability of user actions within the system;� incidential data evaluation vulnerabilities (e.g. in

case of cipher text access);� resistance to censorship;� membership concealment.

3. Functionality (e.g. user handle and content search func-tionality, recommender systems, API).

4. Economical issues� network infrastructure costs and storage resource

provisioning;� type of payment (e.g. money to rent servers or

resource contribution via P2P approach).

3.2. Adversary models

The existence of an omnipotent Social Network Provider(SNP) is considered to be a privacy problem by the authorsof DOSN approaches. The underlying assumption is thatthe provider can neither be trusted to protect user datafrom external attackers nor to withstand misusing the datafor monetization purposes. However, the OSN providermaintains a closed system with little attack surface forexternal attackers. The question thus is whether decentral-ization is the way to go for improving privacy. To discussthis issue, we define the following set of attackers:

1. An adversary which has read and write access to alldata, stored in the system (curious omnipotent SNP).

2. A traffic observer, having an Internet Service Pro-vider (ISP)-like view at the network traffic.

3. An adversary who can enforce all authorities (organi-zations and companies like SNP and ISP) to corporatewith her (governmental attacker).

4. The mass data collector, collecting as much dataabout as many users as possible (e.g. crawler).

5. The stranger adversary which represents an arbitraryuser of the OSN (no direct friendship connection tothe attack target).

6. The friend adversary, defined in [25] which isexploiting the friend connection in the OSN.

7. The online reputation attacker, aiming at destroyingthe reputation of individual users (cyber bullying).

4. DOSN architecture model

The following 3-layer DOSN – architecture model(Fig. 1) introduces an abstraction of the DOSN design space.Subsequently it describes its components which areaddressed by approaches which are covered by this survey


http://https://diasp.eu/stats.html



352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

Fig. 1. Architecture for DOSN.



16 October 2014

Q1

or are core functionalities of today’s popular OSNs. ExistingDOSN approaches individually take just a subset of theoptional extensions into account, but minimally specifythe DOSN core layer.

The lowest layer represents the communication net-work which is used for all participating entities to commu-nicate. We assume that it reliably transmits messages fromone entity to the other. The middle layer, called ’’DOSN –core’’ contains all components which are necessary to pro-vide the basic DOSN functionality. The upper layer repre-sents extensions aiming at making the user experienceenjoyable. It is divided into two sublayers where the lowerpart is hidden from the users and thus provides services forthe elements of the upper part, facing direct userinteractions.

The core component contains three main parts:

� the access control component which can be realizedeither via access policies, via encryption schemes or acombination of both,� the profile storage component which describes how

profile data is stored in the system and� an overlay or federation component to organize the

communication between nodes. We distinguishbetween protocols supporting direct user interactions(communication) and those supporting technical infor-mation exchange (e.g. profile update propagation)where the latter is transparent to the user and hencemay raise different time and volume requirements.

The extensions layer consists of two sublayers. Only thecomponents on the upper layer face direct user interac-tions while components of the lower sublayer are hiddenfrom the user. We define the following hidden modulesof the extensions that implement the extended functional-ity (Section 2):

� API as an interface for third party applications;� a recommender system which can potentially recom-

mend both: friends relationships to create as well ascontent items to consume;� a search scheme which supports privacy preserving

search for user handles or content addresses;� a social network connector, connecting the new DOSN

to existing OSNs, since network effects yield the largestOSN the most attractive since the probability of findingfriends is growing with a growing number of users.

The two components with the closest position fromuser perspective (and hence not hidden from the users)are the GUI (graphical user interface) and the applicationswhich can be built by third parties or users. We considerboth to be on the same layer since applications may realizeown GUIs.

441

442

443

444

445

446

447

5. Desing decisions

Representing the core of our DOSN model and under-standing the different ideas to address the challengesappearing while developing DOSN, lead us to identify the


three main criteria for classification: (i) the way of decen-tralizing the storage of content, (ii) the mechanisms todecentralize access control and (iii) the way how decen-tralized interaction and signaling mechanisms areimplemented.

5.1. Decentralized storage of data

Decentralized storage is a very strong concern of theauthors of OSN. The main idea is to put the data owner intoa position to hold sway over her PII by keeping the datastorage in her influence zone (sphere wherein the user ora trusted third party, e.g. a friend, is directly capable todetermine storing, erasure and access operations). In fact,different storage concepts strongly characterize the differ-ent DOSN approaches, since they have a big impact on thenature of the architecture itself. Three different fundamen-tal types of decentralized storage of content have been pro-posed: storing on (i) peer nodes (P2P-OSN), on (ii) externalpermanent servers (F-OSN) or on (iii) a mix of both (HybridOSN).

In the case of storage on peers (users’ devices), one mainchallenge is to handle churn provoked resource unreliably.To minimize the risk for data loss and data unavailability,redundant service provision is mandatory. Different per-formance implications of redundancy procuringapproaches yield this design decision crucial for P2P-OSNs.Since replication of resources is the only type of redun-dancy leveraged in the literature, one important storage-related system design decision for P2P-DOSN approachesis to choose the nodes where to save the copies (i.e. replicaplacement).

The suggested replica placement strategies are to store:

� data items somewhere randomly in the network;� data on a set of strangers’ devices;� data on friends’ nodes;� data on a chosen subset of friends;� data by leveraging a DTH.

To circumvent the availability issue, the replica place-ment and maintaining effort, storing on reliable externalservers has been suggested. Profile owners in DOSN have




448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557558

559

560

561



16 October 2014

Q1

– in contrast to centralized OSN – the choice where to storetheir data. The criteria for this decision are monetary cost,trust toward the service provider or guaranteed levels ofavailability and reliability. We distinguish between flatstorage on arbitrary resources and F-OSN based on special-ized servers implementing OSN logic at the same place.

Hybrid approaches may allow both: storing data ondedicated servers as well as storing locally on churn-exposed peers.

5.2. Decentralized access control

Since one goal of DOSNs is to improve privacy in OSN(definition in Section 2), DOSN should allow users to defineexactly who is part of the set of legitimate content recipi-ents for each single piece of content. Two general primi-tives have been suggested: access control which isperformed by trusted entities as well as encrypting contentand distributing keys among legitimate recipients. Further-more, mixtures of both primitives are part of someapproaches.

Approaches relying on ACLs are based on the principlethat users have to prove they own necessary rights to anauthority enforcing policies defined in the ACLs to accessor modify a given piece of content. In our classification,we characterized works relying on ACLs based on whoenforces the policies, which can be peers or external serv-ers (based on where data are stored). Finally the ACLs canbe enforced by external services in the form of applicationsor plug-ins, run on the top of the platform, which allowusers to interact with each others.

Data encryption approaches are based on the principlethat anybody can retrieve a piece of content, but only userswho have decryption keys can interprete it. Relying on con-tent encryption for performing AC, implies the definitionof a key management mechanism. In our classification,we thus characterize several works based on the adoptedmechanism.

A motivation for implementing both: an ACL as well asan encryption scheme is that ACL does not protect fromaccess to encrypted content (ciphertext) and thus stillallows for inferring communication details like e.g. thedata size or communication patterns [26].

5.3. Interaction and signaling mechanisms

Interactions among users in terms of sending messagesare at the core of any social platform and may include sig-naling and notification and establishment of new relation-ships, etc. In centralized OSNs, the service providermediates interaction among users.

In DOSNs, interaction mechanisms can be either: (i) stillcentralized, meaning that they are handled by one singlelogical entity (in some cases DOSN still rely on classicalcentralized counterparts for handling interactions [33]) or(ii) decentralized. Decentralized interaction can be realizedbased on a P2P substrate, relying on direct interactionsamong user terminals, on the publish-subscribe modelsor on federation protocols including inter-server commu-nication (e.g. XMPP). Some DOSNs do not define how suchmechanisms should be implemented, rather addressing


lower level aspects and relying on higher level plug-insfor handling interactions.

In our classification, we thus distinguish between cen-tralized and decentralized handling of interactions andpoint out the adopted approach.

6. Resulting effects of design decisions

In this section, we discuss the properties and implica-tions of the respected classes entailed by the basic designdecision elaborated in Section 5.

6.1. Decentralized storage of data

The answer to the question of where is a convenientplace to store data in DOSNs naturally commemoratesthe impacts of the issues of data availability, storage costsas well as trust. Data availability is an important issue incase of using unreliable resources (P2P). Storage costsbecome important in case of applying replication schemesthat maintain multiple copies in the network or in case ofusing dedicated resources. In either case, the storagedevices have to be trusted to reliably serve legitimaterequests and not to leak or misuse accidental data or eventhe content itself if it is not encrypted.

In P2P-OSNs [10,12,24,5,30,36] data availability isbound to the on-line time of the different principals andcan be enhanced thanks to the discussed replication mech-anisms. In [11] several replication mechanisms are dis-cussed, which show how availability increases withreplication granularity.

No matter how the replication nodes are chosen,storage on peers costs storage as well as bandwidthresources which are not for free. Sophisticated approaches[31,46] aim at minimizing resource consumption whilemaximizing profile availability. We briefly describe themin Section 9, since these approaches are just replicationschemes rather then complete DOSN approachesaccording to our definition and hence not part of ourclassification.

However, data replication may affect data consistency,since the latter is significantly harder to achieve as thenumber of copies of a single piece of content, distributedon several nodes, increases. From the user’s point of view,all replication schemes, suggested by the authors of DOSN,come with serious disadvantages:

1. Storing replicas at friends’ nodes� Bootstrapping: it is difficult when entering the net-

work while having no friends.� Correlated failure: the profile cannot be found by

unconnected friends and strangers if all friends areoffline at a given point in time.

� Load balancing is not scalable to popularity peaks ifthe set of replica nodes is fixed and limited to thefriend’s devices, assuming that profile data itemscan be requested publicly (e.g. requests caused bya newspaper article about a person).

2. Random replication without management requires a tohigh number of replicas to be feasible under realisticchurn assumptions [38].




562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

676

677



16 October 2014

Q1

3. Passive replication in which offering access to previ-ously downloaded profiles is granted, does not supportunpopular profiles to stay available since unpopularprofiles are not frequently accessed.

Assuring data availability and integrity is not an issue inF-OSNs, since users may store a single copy of their dataonly on a reliable professional storage which they trustfor not altering or removing their data. Social networkarchitectures relying on flat storage [21] with no OSN-spe-cific logic implemented, allow flexible choice of storageresources, since different types of storage resources (e.g.upload and download services, e-mail boxes or personalweb space services) exist. Users may choose external serv-ers for data storage based on criteria such as technicalspecifications (storage size and bandwidth), trust, mone-tary costs or reliability. The drawback is that there mustbe a place to process the OSN logic and if it is not the stor-age offering server, an additional party, which has to betrusted, is necessary.

In contrast, approaches relying on special OSN serversfor storing user data [44,45,43,6] abolish the need forexternal OSN logic deployment but limit the users inchoosing a storage location to the OSN servers instead ofany arbitrary storage resource.

Hybrid approaches, allowing both: to store on dedicatedservers as well as to store on own hardware (e.g. diaspora),relieve users from the need for external services.

6.2. Decentralized access control

Limiting access to content to a desired set of recipientsis at the core of each privacy concept. Three general con-cepts can be found: ACLs (Access Control Lists), encryptionschemes and a combination of both. All those concepts canbe realized on the granularity of individuals, role basedaccess control as well as access control on the basis of agroup management system.

Restricting access via ACLs can be realized straightfor-ward via granting access to legitimate users after authenti-cation (before accessing content, the knowledge of thesecret needs to be proven) or identities (users being partof a content owner-defined set of legitimate identities areallowed to access).

Since ACLs do not provide any kind of protection againstattackers which are able to listen to the communication atthe underlaying network and access policy enforcing par-ties need to be trusted, several authors of DOSN suggestto implement encryption schemes in spite of their needfor key distribution. In our classification, we thus charac-terize the approaches based on the trusted parties enforc-ing the ACLs and the adopted key management mechanismin case of content encryption.

Most encryption based DOSNs [54,21,7,6] rely on Out-Of-Band (OOB) mechanisms for exchanging the whole keys(or fingerprints of the key that can be used for retrievingthe associated key, for example relying on cryptoIDs [39],as suggested in [6]). This of course implies the disadvan-tage of the need for a secure and trustworthy OOB channel.

As an alternative to OOB mechanisms, Safebook [13],PeerSoN [10,51] rely on trusted nodes playing the role of


Credential Authorities/PKI. In those cases, the CredentialAuthorities (CA) are only used to cryptographically initiatethe OSN, while they do not mediate communications andcannot trace interactions.

Finally, Graffi et al. in [24] propose to rely on a DHT sub-strate also for distributing keys, which allows to avoid anynecessity for a central node in the network. As a conse-quence, there is no need for OOB communication nor Cre-dential Authority, but it comes without any kind ofidentification.

Cryptographic methods which allow malicious partiesto access cipher code still do not prevent from inferenceattacks. Attackers may infer the type of a message (e.g.video vs. chat) from the size. Furthermore, access to ciphercode allows attackers to notice actions (depending on theencryption mechanism) like revocation of access rights oraccess patterns [26]. A combination of limiting access viaACLs and encryption or obfuscating methods like chunkingand salting can mitigate this issue.

6.3. Interaction and signaling mechanisms

Different types of interaction handling mechanismswith contrary implications have been proposed by theauthors of the approaches which are covered by this arti-cle. Interaction includes messaging as well as sharingpieces of content. Sharing operations consist of makingpieces of content available for being downloaded by otherusers. We distinguish between centralized and decentral-ized interaction mechanisms.

6.3.1. Centralized handling of signalingCentralized interaction handling can be achieved by

purpose-built specialized services or via utilizing existingOSNs (e.g. Facebook) for signaling.

The centralized interaction mediation and handling ofmetadata is suggested in [32]. In contrast to centralizedOSNs where resources of a central authority takes care ofdifferent functionalities (e.g. storage, authentication andinteraction management), a (single) central node is respon-sible just for the interaction and metadata handling. Theaim is that interaction handling can be done via reliableand powerful units for achieving good quality of servicewithout having a central authority which is able to accessuser data. The underlaying assumption is that user dataaccess (like in centralized OSNs) is a crucial part of the ser-vice provider’s omnipotence and needs to be abolished.Lockr [53], Polaris [54] and Confidant [33] rely on existingplatforms performing signaling mechanism.

However, centralized interaction and metadata han-dling approaches still give the OSN provider access tometadata and content access information. That meansthe central authority is still able to learn e.g. the interests,social connections and popularity of users and their pro-files. Hence these approaches require the users to trustthe authority to a certain level.

6.3.2. Decentralized handling of interactionsP2P systems often rely on a DHT as a signaling mecha-

nism thus mediating interactions. For example, in Safebook[13], PeerSoN [10] and Vis-a-Vis [47] the DHT system can




678

679

680

681

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

701

702

703

704

705

706

707

708

709

710

711

712

713

714

715

716

717

718

719

720

721

722

723

724

725

726

727

728

729

730

731

732

733

734

735

736

737

738

739

740

741

742

743

744

745

746

747Q5

748

749

750



16 October 2014

Q1

be used as an asynchronous messaging mechanism, whichmay include signaling of new actions/interactions. Userscan query the DHT with the ID of a user or a specific pieceof content.

A unique feature of P2P-OSNs consists of the possibilityof direct interactions among users, also with no Internetaccess, how suggested in PeerSoN [10] and in Polaris[54], at least for some kind of interactions. While PeerSoNrelies on direct data exchange among user devices, inPolaris data may be stored/replicated on external serversand user smart phones only play the role of entry pointto user data.

The decentralized interaction handling comes with themain advantages not to require trust into a single entityfor that (interaction) purpose. Drawbacks are that thosedecentralized systems may leak metadata by cipher evalu-ation [26]. They may also suffer from churn-caused nodeunavailabilities and – like approaches with purpose-builtcentralized interaction mechanisms – from missing con-nectivity to popular centralized OSNs like Facebook.

751

752

753

754

755

756

757

758

759

760

761

762

763

764

765

766

767

768

769

770

771

772

773

774

775

776

777

778

779

780

781

782

783

784

785

786

787

7. DOSN approaches

This section supplements the Table 1 with a short par-agraph of text for each approach. The rationale behind thissection is that a classification cannot capture all uniquedetails of all approaches. The aspects which are alreadycovered in the classification are not mentioned again,except when they are part of the unique clue of theapproach. Advantages and disadvantages of approachesare not discussed in this section for each approach, sincesimilarity of approaches causes redundancy in the evalua-tion. Section 8 encloses an evaluation based on classesinstead.

Furthermore, we explain the publication time line aim-ing at making it easy to grasp when an approach was pub-lished and which approaches can be assumed as known bywhich authors of newer approaches.

7.1. P2P-OSN

7.1.1. PeerSoNThe authors of PeerSon [10] propose a two-tier architec-

ture in which the first tier is a Distributed Hash Table(DHT) and the second tier consists of the nodes represent-ing users. The idea is to use the DHT to find the necessaryinformation for users connecting directly to the targetnodes. This approach comes without a replication schemeand stores offline messages at the DHT (OpenDHT in theprototype implementation). All user content is encrypted.

7.1.2. SafebookMain objective in case of Safebook [13] is to protect pri-

vacy of users in a DOSN setting. The architecture consists ofthree main components, namely: Matryoshkas (a ring-likeego graph reflecting friendship relations), a P2P lookup ser-vice and a Trusted Identity Service (TIS).

Each node is surrounded by its friends (first shell) andfriends-of-friends (second) shell in its Matroyschka. Userprofiles are replicated for better profile availability at


friend’s nodes in the innermost shell. Nodes at the outer-most shell are entry points for routing requests to the cen-ter of the Matryoshka and can be found via querying thelookup service. This overlay structure hides the friendshiprelations from strangers by multihop routing. TIS verifiesuser identities.

7.1.3. LotusNetLotusNet [5] is a modular P2P-OSN platform, realizing

social network functionality in widgets. The communica-tion infrastructure as well as the encryption scheme andthe identify management is realized by using the DHTmodification Likir [4]. Access control is realized by signedgrants for proofing social relations. The data owner hencespecifies the type of social relation which is necessary toaccess the data item (see Fig. 2).

7.1.4. LifeSocial.KOMGraffi et al. [24] present an approach where all OSN

functionality is realized by plug-ins. Storing and exchang-ing data items is realized with the help of FreePastry[41]. PAST [17] is used for data replication. CryptographicPublic Keys are leveraged to be user IDs in the networkthus uniquely identify users in addition to encrypt contentand messages.

7.1.5. DECENTDECENT [30] is a modular and object-oriented architec-

ture DOSN architecture. It leverages a DHT to store userdata and uses cryptography to protect confidentiality andintegrity of user-owned content. The focus of the authorsis a blog-like wall rather than chat messages. The architec-ture is modular, i.e. the data objects, cryptography andDHT are three separate components interacting with eachothers based on an interface. This modularity causes free-dom to use any kind of cryptography (ABE based on [29]is suggested in DECENT) and any type of DHT.

7.1.6. CachetCachet [36] is an improvement of DECENT. Thus it is

also a decentralized architecture for social networks thatprovides strong security and privacy. The main differenceis that Cachet introduces social caches to improve the per-formance of the system by avoiding the pull-based grasp-ing of many single data items from different sources.Therefore nodes leverage social trust relationships to‘‘maintain continuous secure (SSL) connections with onlinecontacts to receive updates directly as soon as they areproduced’’. In case of overlapping online times, this typeof presence protocol can effectively reduce communicationdelays.

7.2. F-OSN

7.2.1. SoNetSoNet [44] circumvents the implications of P2P mecha-

nisms (like profile availability and free-riding attempts inresource provision) by suggesting an XMPP-like architec-ture. Every node is attached to one server, implying theaddress scheme to be user@host (RFC 822). Profile data isencrypted and replication is still part of the architecture




788

789

790

791

792

793

794

795

796

797

798

799

800

801

802

803

804

805

806

807

808

809

810

811

812

813

814

815

816

817

818

819

820

821

822

823

824

825

826

827

828

Fig. 2. Time line of the publication dates.



16 October 2014

Q1

to mitigate server failures. The clue of this approach is toobfuscate the social graph by introducing single directionpseudonyms.

829

830

831

832

833

834

835

836

837

838

839

7.2.2. MantleMantle [21] is a DOSN approach, settled around the idea

to leverage arbitrary storage in the web (cloud services aswell as mailboxes, etc.), to store user data. Since the arbi-trary storage concept disallows storage entities to deployany logic, the service-related logic is implemented inuser-owned clients. Interaction is managed by employinga publish/subscribe model and is handled locally withoutany help of centralized server.

840

841

842

843

844

845

846

847

848

849

850

851

852

7.2.3. PrPlPrPl [45] stands for Private Public. The main goals are to

allow users to store data in their own influence zone bychoosing trusted storage resources and to run social appli-cations across different domains while sharing data with-out privacy concern. The idea of the architecture is tohave Personal Cloud Butlers to store personal digital assetsto support access control mechanisms. A Pocket Butlerhandles all authentication and communication with per-sonal cloud Butler along with the facility to allow sharingof resources across multiple applications.

PrPl uses SociaLite: a language based on Datalog whichallows developers to access the data by just querying onthe data served by Butlers. OpenID is used forauthentication.

853

854

855

856

857

858

859

860

861

862

863

864

865

7.2.4. DiasporaThe main aim of Diaspora [43] is to build a reliable and

usable decentralized online social network. The architec-ture is based (similar to PrPl) on a client–server modelwhere every user has his own server instance (Pod) whichis used for storage, communication and access control.Since there is no data or service replication, pods mustalways be online for reliable service provision. A Pod canbe hosted either on own hardware or by a service provider(cloud service) Data is stored unencrypted on the pod, pro-tected by an access control mechanism.


7.2.5. [Anderson]The authors of [6] define a privacy preserving architec-

ture for decentralized social networking that takes advan-tage of the simplicity and performance of the centralizedclient–server model. The main goals are to protect personaldata from unauthorized access, to hide the social graph(like friendship links) as well as assuring content integrity.

The ideas described in this approach are closely relatedto the field of software engineering rather than networkarchitecture. The authors suggest the client software toconsist of the following layers: the application layer, thedata structures layer, the cryptographic layer and the net-work layer. The layered architecture render the softwarecomponents on each layer exchangeable. All applicationsare supposed to run in a sandbox, allowing the applicationsto access just a predefined subset of the private data.

7.3. Hybrid DOSN

7.3.1. Vis-à-VisA VIS (virtual individual server) [47] is a reliable per-

sonal server, assigned to every user to store her data. Themain idea is to build overlay networks (with VISs as mem-bers) that correspond to social groups. Members of groupsare supposed to have the intention to share their location.The focus of Vis-à-Vis is to support location-based OSNswhile preserving privacy of location information by sup-porting flexible degrees of location sharing in differentgroups.

7.3.2. [Kryczka]In this approach, a User Assisted OSN (uaOSN) [32] is

proposed where users can contribute resources to reducethe costs of the OSN provider and to increase scalability.In uaOSN, queries are sent to the provider which informsthe user about storage placement for large content itemslike photos or videos. The uaOSN provider stores the userprofiles and metadata of the outsourced content. Data inuaOSN can be either stored on user’s desktop or set topbox/residential router which can have a hard disk or onpaid storages like Amazon cloud services. To achieve bettera profile availability, data is replicated. An encryptionscheme is not part of this approach.




866

867

868

869

870

871

872

873

874

875

876

877

878

879

880

881

882

883

884

885

886

887

888

889

890

891

892

893

894

895

896

897

898

899

900

901

902

903

904

905

906

907

908

909

910

911

912

913

914

915 Q6

916

917

918

919

920

921

922

923

924

925

926

927

928

929

930

931

932

933

934

935

936

937

938

939

940

941

942

943

944

945

946

947

948

949

950

951

952

953

954

955

956

957

958

959

960

961

962

963

964

965

966

967

968

969

970

971

972

973

974

975

976



16 October 2014

Q1

7.3.3. [Raji]Similar to the uaOSN, Raji et al. propose in [40] to store

private data (encrypted) beside the OSN on personal stor-age servers which are assumed to be honest but curious.A BE scheme enforces the access control as well as the con-fidentiality of the data.

7.3.4. PolarisPolaris [54] is an ‘‘architecture for OSNs that preserves

monetary incentives for OSN providers to store and man-age user data, while also mitigating the systemic privacyconcerns associated with monolithic OSNs.’’ To realize this,a user can choose a different provider for each functional-ity (e.g. photo storing or microblogging). Highly sensitivedata is stored at a mobile phone which is assumed to beable for keeping small pieces of content available. Theauthors argue that as a result every provider which isinvolved in service provisioning can just access a subsetof the whole personal data.

7.3.5. ConfidantConfidant [33] fosters decentralized data-processing

being scalable and affordable by storing data withoutencryption. It relies on social trust relationships in friendsto replicate the data on secure devices. The challengesaddressed in this paper are to manage access control andto assure data consistency among the distinct replicas.

7.3.6. VegasVegas [18] is a DOSN architecture proposing to use reli-

able data storages for increasing the availability of userdata in a P2P setting. The encryption scheme based mutualpublic keys for exchanging symmetric keys is used toensure the confidentiality of user data.

8. Evaluative discussion

In this Section, we discuss the present situation in thefield of DOSNs on the way to become an alternative to theircentralized counterparts. We thus elaborate the degree ofachievement with respect to our requirements. We focuson the fitness of the DOSN approaches to help to improveprivacy as well as on the quality of user experience. Wediscuss the latter by looking at performance issues,resource provision, technical knowledge which is neces-sary to use the DOSN and finally the offered functionality.

8.1. Privacy and security

The major reason for authors to suggest a distributedapproach for social networking is to increase privacy andsecurity. Hence, the enthralling question is: Are the sug-gested approaches appropriate to achieve better privacyand security? We discuss this question with respect toour adversary models (Section 3.2).

8.1.1. SNP attackerThe overwhelming majority of approaches abolishes the

SNP completely and hence it does not exist as attackeranymore.


The user-assisted OSN (uaOSN)-approach of Kryczkaet al. uses user devices for data storage. Even though theusers may be able to exactly specify which data is sensitive(we doubt that, since sensitivity is depending on theknowledge of the attacker) and store this data on privatestorages, the OSN provider is still able to learn sensitivefacts about the users by evaluating incidental data. TheSNP may learn habits like diurnal usage patterns (e.g. con-clude that the user works at night) and the social graph.That issue applies for Polaris in the same way, since everyprovider of a particular functionality can learn usage pat-terns and two-sided actions like messaging (sender andreceiver) potentially leak knowledge about social relation-ships. We argue that it is necessary to hide metadata andcommunication habits as well as social graph informationfrom the SNP to protect user’s privacy.

8.1.2. Traffic observerThe situation in the field of P2P-OSNs is that all

approaches implement some kind of encryption. Assumingthat the attacker is not able to decrypt ciphers, she is stillable to infer who communicated with whom and howoften. Furthermore, the data item sizes can be inferred byobserving the traffic. This allows for guessing what kindof data is exchanged (chat messages, photos or videos). Ifreplication schemes rely on social graph metrics (e.g.friendships or trust), those can potentially be observed aswell. Only one approach, covered by this survey (Safe-book), tackles these issues by redirection schemes or trafficobfuscation.

Safebook introduces the concept of Matryoshkas wherefriends form ring-like structures in egocentric networks.Traffic is redirected from outer to inner circles. Neverthe-less, Matryoshkas are still vulnerable to timing and trafficobservation attacks since there is no traffic obfuscationor message throttling included.

Inferring facts by observing traffic in F-OSN can be chal-lenging if more than one user is using one server and if theservers are re-encoding the data items, since the trafficobserving attacker can than only observe that a set of usersis connected to the server but not who exactly communi-cates with whom. The success of the attacker depends onhow much information can be learned from communica-tion intensity (traffic, data size) and timing attacks.

Considering hybrid solutions, the situation stronglydepends on the concrete architecture. They are as vulnera-ble to traffic observing attacks as P2P solutions are if directcommunication happens among peers or if it can beinferred from the storage place to which the latter isassigned. Approaches like Polaris [54] may mitigate thesuccess of traffic observers by combining different central-ized services for communication and storage. The uaOSN[32] cannot be evaluated by now, since it is highly depen-dent on what exactly is stored at the peers and how it isaccessed. A caching mechanism in the centralized part ofthe uaOSN can be a game changer for traffic observing.

8.1.3. Governmental attackerGovernments tend to try to censor or even disable social

networks as soon as riots start in that country. The Arabspring is a prominent example for that phenomena. Gov-




977

978

979

980

981

982

983

984

985

986

987

988

989

990

991

992

993

994

995

996

997

998

999

1000

1001

1002

1003

1004

1005

1006

1007

1008

1009

1010

1011

1012

1013

1014

1015

1016

1017

1018

1019

1020

1021

1022

1023

1024

1025

1026

1027

1028

1029

1030

1031

1032

1033

1034

1035

1036

1037

1038

1039

1040

1041

1042

1043

1044

1045

1046

1047

1048

1049

1050

1051

1052

1053

1054

1055

1056

1057

1058

1059

1060

1061

1062

1063

1064

1065

1066

1067

1068

1069

1070

1071

1072

1073

1074

1075

1076

1077

1078

1079

1080

1081

1082

1083

1084

1085

1086

1087

1088



16 October 2014

Q1

ernmental type of attacker can (simplified) be consideredbeing a unification of the SNP attacker as well as the trafficobserver. The questions is: Is there an approach which canresist the governmental attacker?

Even though assuming that the government does notwant to disable the whole communication infrastructureof a country to disable social networking, we argue thatnone of the approaches is bullet proof. P2P approaches(without traffic obfuscation) are vulnerable to trafficobserving attacks: Governments could find out who com-municates with whom and who is important for organizingdemonstrations. Server-based architectures can easily bedeactivated if the servers are well known and run withinthe influence zone of the government. From our point ofview, research in making DOSN more resilient against gov-ernments is eligible.

8.1.4. StrangerStranger attacks with the goal to learn private facts

about a particular user would be very weak if people woulduse the access control mechanisms in OSNs properly and ifthey would be aware of inference attacks (assuming factsto be valid also for friends). The success of stranger attacksare in general less depending on the architecture of DOSNbut rather on efficient access control. Perfect usageassumed, none of the presented DOSN open an attack sur-face for stranger attacks.

8.1.5. Mass data collectorState of the art for mass data collection is building

crawlers. That could be possible if data items arepublicly-accessible and if user handles are available toaddress profiles. The straightforward approach forcrawling a social network is to first create a user accountthen initially connect to arbitrary users and try to crawltheir friend lists.

Iterating over friend lists can theoretically lead to a dis-covery of the whole connected region if every user allowsto access a list of her friends. Hence, no matter at whichtype of architecture, it is very important to disallow strang-ers accessing friend list in general. DOSN architectures thusdo not help to mitigate attacks from mass data collectors incase that access to profiles is restricted in centralized OSNs.

8.1.6. Friend attackersFriends, being attackers aiming at accessing more infor-

mation than authorized by the data owner, can be success-ful either when access control is not performed properly orif replication schemes in P2P-OSN rely on social trust. Anode where friend’s (encrypted) content is stored can stilllearn incidental data.

8.1.7. Cyber bullyingThe social phenomena to attack the reputation of an

individual can be observed in an environment like OSNas well. In a centralized setting without content encryp-tion, the omni-potent provider can delete content as wellas user accounts if the well-behavior rules are notrespected by users. No author of a DOSN considered misbe-havior of users by now. To tackle that issue, accountabilityof actions (e.g. posting content or messages) needs to


become a focus of DOSN. Accountability, however, mayaffect the achievement of anonymity goals.

8.1.8. Conclusion for the privacy and security evaluationThe main advantage in privacy protection, which can be

achieved with the approaches in this survey, can be seen inprotecting against the central OSN provider. Authors tendto protect communication content rather than hiding com-munication. From our point of view, no approach can pro-tect against the governmental attacker being interested inbuilding communication graphs.

Censorship is not an issue in most DOSN (in Polaris anduaOSNs it still is) because of the usage of cryptography.That implies that it is hard to frustrate illegal actions. Ille-gal content can be shared with only a minimal risk andattacks on the reputation of users are abetted. The answerto the general question whether DOSNs improve privacyand security of users strongly depends on the point ofview: DOSN can effectively protect the content which isshared but they may foster misusage.

8.2. User experience

Measuring user experience by conducting a user studyin DOSN is hard to perform since no DOSN (except Dias-pora) has a user basis rather than public-available andusable prototypes. Having no better alternative, we discussperformance issues, the skills being necessary for usingDOSN and the functionality instead.

8.2.1. PerformanceP2P approaches replace the database queries in central-

ized OSN by vast inter-node messaging for accessing data.The authors of Safebook [13] consider 11 s to be a realistictime for requests if no performance optimizations areemployed. Cachet introduces a caching strategy forimproving the performance by maintaining encryptedchannels to friends. Receiving unpredictable data itemsfrom strangers (e.g. friend-of-friend) still causes time con-suming operations.

F-OSN and Hybrid approaches do not suffer from theseP2P-specific performance limitations, but still cause feder-ation overhead. In general we would see a performanceadvantage for centralized OSNs since a single authority isable to globally optimize its databases and to build caches.

8.2.2. UsabilityIf DOSNs leverage cryptography for privacy, basic

knowledge about cryptography may be necessary to usethe DOSN. For example, users need to understand that theyneed to exchange public keys. Furthermore, the presentedapproaches (except Polaris) require users to install a clientsoftware instead of being only a web application. Installingsoftware on local machines may cause a need for actionswhich require administrative rights on the local system.Moreover, the necessity of local software installationscould cause interoperability issues and is an additionalprocedure which might be an obstacle for users. We thusargue that any kind of DOSN should be running at everyweb-connected device without installation obstacles to




1089

1090

1091

1092

1093

1094

1095

1096

1097

1098

1099

1100

1101

1102

1103

1104

1105

1106

1107

1108

1109

1110

1111

1112

1113

1114

1115

1116

1117

1118

1119

1120

1121

1122

1123

1124

1125

1126

1127

1128

1129

1130

1131

1132

1133

1134

1135

1136

1137

1138

1139

1140

1141

1142

1143

1144

1145

1146

1147

1148

1149

1150

1151

1152

1153

1154

1155

1156

1157

1158

1159

1160

1161

1162

1163

1164

1165

1166

1167

1168

1169

1170

1171

1172

1173

1174

1175

1176

1177

1178



16 October 2014

Q1

achieve a usability which is comparable with centralizedOSNs.

8.2.3. FunctionalityNo DOSN provides the same functionality like Facebook.

One reason of course is that the approaches are academicand concentrate on a particular ideas to present ratherbeing intended to be a social network which can be usedby the users.

The second reason is more wholesale in nature: popularfunctionality like recommender systems, search function-ality and some online games leverage the social graphand user attributes. Having only local knowledge, thewhole social graph is not known to any single entity. Thelocal (egocentric) structure can be learned via exchangingmessages, functionality based on global knowledge willbe too expensive.

Acquiring the graph knowledge beyond the own graphneighbors (friends) via messaging may effect the user pri-vacy. Even paramount functions like a sophisticated searchmechanisms for user handles is not available in a privacypreserving manner.

8.2.3.1. Conclusion for the user experienceevaluation. Considering our metrics for the user experi-ence, the presented approaches (except uaOSN) will sufferdisadvantages in comparison with centralized OSNs. Thisholds for performance as well as for the skills and the func-tionality. We consider F-OSN and Hybrid DOSN to have thebiggest potential to present a good trade-off: they can beweb-based as OSN are nowadays, do not suffer the perfor-mance limitations caused by maintaining P2P structures,and in case that the majority of friends is assigned to oneserver, they allow efficient local operations instead ofgrasping data items from a high number of differentsources.

1179

1180

1181

1182

1183

1184

1185

1186

1187

1188

1189

1190

1191

1192

1193

1194

1195

1196

1197

1198

1199

1200

1201

9. Related approaches

We discuss some approaches in this Section whichaddress DOSN related issues or approaches only aimingat improving specific sub-aspects of DOSNs to highlightcurrent challenges. We include approaches addressingthe profile availability issue in P2P DOSNs, encryptionschemes for DOSN as well as for centralized OSN beingone alternative to distributing OSN and finally we includesocial network integrators.

Social network integrators are also included, since theyoffer potential ways of extending the initially limited userbasis of DOSN to temporarily increase their attractivenessuntil sufficient adoption. We thus think that a social net-work connector is a crucial success component for newupcoming social networks.

9.1. Profile availability in P2P OSN

The load and requirements for storage in P2P-OSNsdiffers strongly from distributed storage as well as fromfile sharing. OSNs environments require the storage layerto reliably store many unpopular content items which


are frequently updated. This is in stark contrast to file shar-ing applications, which usually provide a comparativelylow number of large and popular files to a high numberof users. A stark contrast exists even to conventional P2Pbackup and storage scenarios, which are characterized byrather infrequent I/O access to the stored data. Further-more, contrary to file sharing and P2P backup and storage,in which all participants are treated somewhat identical,OSNs contain information about friendship and trust rela-tionships that can be exploited. Many techniques that aredeployed in P2P storage environments – like erasure codes– are not convenient in this dynamic environment. Thus,none of the P2P-OSN approaches is based on a file sharingnor P2P storage scheme. The following subsection explainsthe solutions for profile availability in P2P-OSNs that arediscussed in the literature.

As shown in [38], choosing replication nodes randomlyleads to a high number of replicas if a convenient availabil-ity of user profile data should be achieved. Friend storageapproaches suffer from localization effects: if all friendslive in the same time zone (e.g. same city), it is very likelythat they have the same off-line times in the night. Fur-thermore, if a new node has no connections to friends, itdoes not benefit from replication. Choosing the best subsetof friends for profile replication is an NP-hard problem[49].

Finding a systematic solution for having a good avail-ability with minimum of cost and overhead is the goal ofthe authors of MY3 [35], SuperNova [48], Gemstone [52],SOUP [31] and S-Data [46].

SuperNova introduces super nodes for bootstrappingand circumventing the disadvantages of utilizing friends’nodes for storing. Gemstone has a metric-based approachto select some friends which are a good choice for achiev-ing a high availability with low costs and SOUP proposes toselect replica nodes by calculating an online experienceamong friends. S-Data is a group-based approach wheregroups are generated on the basis of diurnal online pat-terns to reduce the number of replicas. The authors ofMY3 [35] propose users to choose a subset of friends(trusted proxy set) for performing profile replication andaccess control. Arguing that trusting the friends whichare performing the access control can replace the encryp-tion of content and hence abolishing key distribution. Thisassumption simplifies the approach.

9.2. Encryption schemes for OSNs

Abolishing the omnipotent and trusted social networkprovider as a mediator of communication between socialnetwork users, combined with the introduction of replica-tion schemes in P2P-OSN, leads to the need for encryptionof content and communication (in case of leveraginguntrusted resources). F-OSNs or hybrid solutions oftenaim at mitigating the need for trusting server entities andrely on cryptography for this purpose. Only a minority ofDOSN approaches comes without encryption and relieson trust in friends (e.g. My3 [35]).

Thus, the efficiency, performance and usability ofencryption and key distribution schemes are crucial factorsfor DOSNs for being widely adopted. For this reason, some




1202

1203

1204

1205

1206

1207

1208

1209

1210

1211

1212

1213

1214

1215

1216

1217

1218

1219

1220

1221

1222

1223

1224

1225

1226

1227

1228

1229

1230

1231

1232

1233

1234

1235

1236

1237

1238

1239

1240

1241

1242

1243

1244

1245

1246

1247

1248

1249

1250

1251

1252

1253

1254

1255

1256

1257

1258

1259

1260

1261

1262

1263

1264

1265

1266

1267

1268

1269

1270

1271

1272

1273

1274

1275

1276

1277

1278

1279

1280

1281

1282

1283

1284

1285

1286

1287

1288

1289

1290

1291

1292

1293

1294

1295

1296

1297

1298

1299

1300

1301

1302

1303

1304

1305

1306

1307

1308

1309

1310

1311

1312

4 http://onesocialweb.org/, accessed on 20th of January 2014.



16 October 2014

Q1

authors work on building new cryptographic mechanismsfor that specific issue. Mentioning their relevance, we pres-ent a brief sketch of the ideas and a brief overview of thisfield.

9.2.1. Brief OSN encryption backgroundMutual public keys are the straight forward type of real-

izing an encryption. For every recipient of a message, oneencryption procedure has to be performed. Asymmetriccryptography, however, is comparatively expensive com-pared with symmetric cryptographic algorithms. Groupkey management mechanisms based on symmetric keystackle that issue by distributing one symmetric key amonga group of recipients (e.g. via mutual public key schemes).Hence, one (symmetric) encryption process is sufficient toshare content with a group of recipients. As long as thegroup setting does not change, a new key distribution isnot necessary.

Broadcast encryption (BE) schemes can rely either onsymmetric or asymmetric encryption and are used bysenders to share confidential data with a dynamic set ofrecipients in a cost-effective way. BE requires each recipi-ent to have an individual key. In BE schemes, the encryptoruses an encryption mechanism that allows to produceciphertext that can be decrypted by plenty of keys whichare defined during the encryption process. If a privatekey generator, leveraging identities to decide about legiti-mation is part the system, the broadcast encryptionscheme is called identity based broadcast encryption(IBBE) [15,9].

Attribute based encryption (ABE) [42,23] schemesadopt that idea. An encryptor decides who is able todecrypt the ciphertext by labeling the latter with a set ofdescriptive attributes. Private keys are associated withACL structures to decide, based on those attributes, whichciphertexts can be decrypted. The encryptor thus does notdecide about decryption by taking single keys or identitiesinto account but defines attributes or combinations ofattributes which a decryptor needs to meet to be able todecrypt a message.

9.2.2. (D) OSN encryption contributionsThe main goal of Persona [7] is to disallow third parties

to access personal information by deploying attribute-based encryption (ABE) in an OSN context. Each user gen-erates an ABE public key (APK) and an ABE master secretkey (AMSK). For each friend, the user can generate anABE secret key (ASK) corresponding to the set of attributesthat defines the groups that friend should be part of.

The main contribution of the model from Sun et al. [51]compared with Persona is to have a very efficient revoca-tion of content access rights. It uses broadcast encryptionthat enables the data owner to exercise desired accesscontrol.

The authors of Noyb [27] (‘‘none of your business‘‘) sug-gest to improve privacy by encrypting content and to mod-ify it in a way that it looks like legitimate content. Hence, itallows users to use existing OSN while disallowing pro-vider to access the content. Applying this approach is notan obstacle for the provider to learn usage patterns as wellas friendship relationships.


Günther et al. [28] provide a building block for privacypreserving treatment (including encryption) of user pro-files in OSNs. The authors of [8] compared differentencryption mechanisms and evaluated them for theirapplicability in the DOSN context and concluded thatbroadcast encryption would be the best choice for thisuse-case.

EASIER [29] is an ABE architecture for DOSN, supportingdynamic group memberships and revocation of rightswithout re-encrypting data items or issuing new keys.The main idea is to introduce a proxy which needs to becontacted before decryption. A user sends a part of thecipher text (CT) to the proxy where a transformation takesplace. The transformed CT can only be decrypted if theright was not revoked.

Lockr [53] is an identity-management tool for OSNs thatallows users to codify their relationships through socialattestations. The primary goal is to provide privacy as wellas to simplify site management and accelerating contentdelivery. Lockr’s decoupling eliminates the burden onusers of maintaining, several up-to-date copies of socialnetworks, performing user-ID reconciliation across sites,and familiarizing themselves with the varied access con-trol mechanisms provided by each site. A social attestationis a piece of data that certifies a social relationship. By issu-ing an attestation, the issuer tells a recipient that they haveformed a relationship.

The presented encryption approaches show that retain-ing confidentiality of content in OSNs is possible. In case ofsuggesting a new DOSN approach, authors may rely onexisting encryption mechanisms.

9.3. Private discovery of common social contacts

Discovering common social contacts is a common fea-ture in today’s OSNs like Facebook. In privacy preservingdistributed systems, it may not be desired to exchangecontact lists. De Cristofaro et al. [14] introduces a schemewhich allows for finding common friends without disclos-ing non-common friends. To the best of our knowledge,there is no discovery mechanism which neither disclosethe search index nor the search queries. As a result, thereis a trade-off between implementing (or using) a discoverymechanism or preserving privacy with respect to searchindex and queries.

9.4. Social network integrators

OneSocialweb4 is a project aiming at building an XMPP-based connector which potentially integrates all OSNs intoone large social network. Other social network integrators,connecting a subset of popular services are:

1. Meople (http://meople.net/, accessed on 20th ofJanuary 2014) aggregated SNSs: Facebook, LinkedIn,Google+, Twitter, Instagram, YouTube, Flickr,Groupon, Tumblr, Foursquare, VK, Odnoklassniki.


http://meople.net/

http://onesocialweb.org/



1313

1314

1315

1316

1317

1318

1319

1320

1321

1322

1323

1324

1325

1326

1327

1328

1329

1330

1331

1332

1333

1334

1335

1336

1337

1338

1339

1340

1341

1342

1343

1344

1345

1346

1347

1348

1349

1350

1351

1352

1353

1354

1355

1356

1357

1358

1359

1360

1361

1362

1363

1364

1365

1366

1367

1368

1369

1370

1371

1372

1373

1374

1375

1376

1377

1378

1379

1380

1381

1382

1383

1384

1385

1386

1387

1388

1389

1390

1391

1392

1393

1394

1395

1396

1397

1398

1399

1400

1401

1402

1403

1404

1405

1406

1407

1408

1409

1410

1411

1412

1413

1414

1415

1416

1417

1418

1419

1420

6 http://www.facebookcensorship.com/, accessed on 20th of January2014.



16 October 2014

Q1

2. Jyst (http://jyst.us/, accessed on 20th of January2014) aggregated SNSs: Facebook, Twitter.

3. Alternion (http://www.alternion.com/, accessed on20th of January 2014) aggregated SNSs: Facebook,LinkedIn, Twitter, Instagram, YouTube, Flickr, Four-square, Picasa and the mail accounts: Gmail, Hot-mail, Yahoo!, AOL.

4. Yoono (http://www.yoono.com/, accessed on 20th ofJanuary 2014) aggregated SNSs: Facebook, LinkedIn,Twitter, YouTube, Flickr, Foursquare, MySpace,Yahoo!, Google Talk, AIM, FriendFeed.

5. TweetDeck (http://www.tweetdeck.com/, accessedon 20th of January 2014) aggregated SNSs: Twitter,Facebook, Myspace, Linkedln, FourSquare,GoogleBuzz.

6. Hootsuite (http://hootsuite.com/, accessed on 20thof January 2014) aggregated SNSs: Facebook, Linked-ln, Foursquare, MySpace, PingFm, Wordpress.

7. SpredFast (http://spredfast.com/, accessed on 20th ofJanuary 2014) aggregated SNSs: Facebook, Twitter,LinkedIn, Google+, YouTube.

The aforementioned social network connectors couldpotentially been leveraged to bootstrap a new (D) OSNsince the attractiveness of OSNs is strongly bound to theuser basis.

10. Impacts on stakeholders caused by thedecentralization of OSN

In this Section, we discuss the impact of decentralizingOSN on today’s OSN stakeholders. This includes benefits,drawbacks and challenges.

The stakeholders in the context of OSN, considered inthis work, are: the OSN users, the OSN provider, the adver-tising companies which benefit from utilizing the advertis-ing opportunities offered by the OSN provider, thegovernmental state and media consumers which are notnecessarily part of an OSN. Effects on extenders (e.g. appli-cation sellers) like Zynga5 are not discussed since the effectson them is strongly depending on the particulararchitecture.

Since we consider the user to be the most importantaffiliate, we start our discussion with the following bene-fits of OSN decentralization for the users:

� Ownership: Facebook and other OSN provider ask theusers to transfer the copyrights of any content fromthe user to the OSN owner. In contrast, decentralizationholds user data in the influence zone of the users (Sec-tion 2). The copyright transfer can be avoided.� Privacy: In centralized OSNs, users need to trust the

omnipotent provider not to misuse the data and to beable to protect the data from attackers.� Flexible choice of resources: Building, running and main-

taining OSN platforms cause expenditures. In central-ized OSNs, platform-related resources are provided bythe service provider itself. In most cases, they present

5 http://zynga.com/, accessed on 06th of July 2014.


no monetary costs to the final users [20], which payby agreeing for such platforms to exploit their data witha commercial purpose.One of the benefits a decentralized approach shouldbring to users, is that they should have the possibilityto choose what resources to rely on. For example, a usercan choose whether adding the own device’s resources(e.g. P2P approaches) or relying on dedicated servers(e.g. Diaspora). Using dedicated resources for buildingDOSN does not cause an exploitable dependency likeusing the resources of centralized OSN provider, sincethe OSN membership does not require an affiliationwith one specific authority. Hence, the resource pro-vider is replaceable.This opens to several business models which stronglydiffer from exploiting user data for commercialpurposes.� No censorship: Several centralized OSNs perform active

censorship6,7 – called decency or content control – onuser behavior and content. This imposes significant limi-tations on what a user can or cannot do within the plat-form, based on rules which may strongly vary from oneplatform to another and are in general very subjective.Such rules can also be very country-specific, since OSNshave already accepted to be compliant to local lawsimposed by several governments.� Openness: DOSNs abolish the central authority, causing

that no single authority is able to exclude a user fromthe platform by suspending his account (e.g. becauseof not accepting copyright transfer rules).

While decentralizing OSNs does not come withoutdrawbacks, the following aspects may become an issuefor users:

� Resource provision: Centralized as well as decentralizedOSNs need technical resources (e.g. storage, bandwidth)to operate. In centralized OSNs, the provider is respon-sible for making them available. The most popularapproach to compensate these efforts is to sell opportu-nities for personalized advertising. In the decentralizedcase, other mechanisms need to tackle the resourceissue.� Profile availability: Availability of user profiles is

strongly linked to the architecture of an OSN. In the cen-tralized case, the provider takes care of storing andkeeping user profiles available. Federated DOSNs relyon independent professional and reliable resourceswhile P2P OSNs utilize the unreliable resources of theusers devices.� Cyber bullying: Since decentralized OSNs hide or encrypt

the communication, no central authority can enforcerules. In the real world, no administrator can switchoff the voice of people which are bullying others as well,

7 http://www.dailytech.com/Google+Plays+Name+Police+Conducts+Baf-fling+Censorship+Crusade/article22238.htm, accessed on 20th of January2014.


http://jyst.us/

http://www.alternion.com/

http://www.yoono.com/

http://www.tweetdeck.com/

http://hootsuite.com/

http://spredfast.com/

http://zynga.com/

http://www.facebookcensorship.com/

http://www.dailytech.com/Google+Plays+Name+Police+Conducts+Baffling+Censorship+Crusade/article22238.htm

http://www.dailytech.com/Google+Plays+Name+Police+Conducts+Baffling+Censorship+Crusade/article22238.htm



1421

1422

1423

1424

1425

1426

1427

1428

1429

1430

1431

1432

1433

1434

1435

1436

1437

1438

1439

1440

1441

1442

1443

1444

1445

1446

1447

1448

1449

1450

1451

1452

1453

1454

1455

1456

1457

1458

1459

1460

1461

1462

1463

1464

1465

1466

1467

1468

1469

1470

1471

1472

1473

1474

1475

1476

1477

1478

1479

1480

1481

1482

1483

1484

1485

1486

1487

1488

1489

1490

1491

1492

1493

1494149514961497149814991500150115021503150415051506150715081509151015111512



16 October 2014

Q1

but everybody is responsible for what he or she is doing.We argue that DOSN should support accountability toprotect users.� Metadata privacy and the concealment of communication

partners: Depending on the particular architecture,decentralizing OSNs may raise security issues that donot exist in centralized OSNs [26]. An attacker whichis able to observe traffic in the underlying communica-tion network (e.g. IP) could track who communicateswith whom if OSN devices are assigned to a single userand can send messages to other devices without obfus-cation. In contrast, a centralized OSN has a mixing func-tionality. Assumin frequent usage, mixing functionalityimplies that the observer could only find out that userscommunicate with the provider but not track singlecommunication paths among users.� Functionality: OSNs allow to build social applications

which are based on interactions between users whoshare social links or special interests. Examples forthese applications are recommender systems, interestmatching algorithms for mediating between users aswell as games. Due to the nature of decentralized sys-tems, the complete social graph as well as the completeset of interests of all users is not known to anybody.Each node has only local knowledge. Hence, the graphknowledge needs to be grasped using federation proto-cols, if it is necessary for an application.

Other affiliates become more affected by economicalissues. Abolishing the central OSN provider naturallydestroys their business model and hence other companiescannot benefit any more from utilizing the advertisingopportunities.

151315141515151615171518151915201521152215231524152515261527Q7152815291530153115321533153415351536153715381539154015411542154315441545154615471548

11. Summary and conclusion

In this article, we discussed the impact of decentralizingOSNs on different OSN affiliates of today’s popular OSNs,explained the design space by introducing an architecturemodel, presented and discussed a classification of DOSNapproaches and introduced some DOSN-relatedapproaches. Finally, we presented the unique ideas of eachdiscussed approach.

Decentralization of OSN can tackle two importantissues: First, it is a possibility to circumvent the need totrust the SNP for not learning facts which cannot been hidedby encryption. An omnipotent provider could still learn whocommunicated with whom and how often. Second, users donot need to accept copyright transfers to the SNP and termsof usage which are disadvantageous for them.

The result from security perspective is that DOSNsmainly aim at protecting content from curious providerand assuring confidentiality of user communication. DOS-Ns potentially abolish content censorship by leveragingencryption schemes Beside Safebook, none of the pre-sented approaches introduces mechanisms to protectagainst traffic observer or governmental attackers buildingcommunication graphs.

The result of our functionality discussion is that the dis-cussed ideas do not solve the issue of providing attractive


social-graph based functionality like a comprehensive pri-vacy preserving search and a recommender system like inthe centralized OSN counterparts. Hence, we argue that thefield of DOSN could benefit from research in building pri-vacy preserving graph-based functionality, combined withperformance optimizations.

Acknowledgements

This work has been [co-]funded by the GermanResearch Foundation (DFG) in the Collaborative ResearchCenter (SFB) 1053 ’’MAKI – Multi-Mechanism-Adaptationfor the Future Internet’’.

This research in parts has been funded by the MSIP(Ministry of Science, ICT & Future Planning), Korea, in theICT R&D Program 2013.

References

[1] Censorship in Facebook. <http://www.rechtzweinull.de/archives/840-Zensur-bei-Facebook-Reichweitedes-virtuellen-Hausrechts.ht-ml> (accessed 2014-01-16).

[2] Censorship of Femen in Facebook. <http://www.mmnews.de/index.php/etc/13534-facebook-zensiert-femen> (accessed 2014-01-16).

[3] Facebook Censorship in Syria. <http://www.reuters.com/article/2007/11/23/us-syria-facebook-idUSOWE37285020071123> (acces-sed 2014-01-16).

[4] Luca Maria Aiello, Marco Milanesio, Giancarlo Ruffo, RossanoSchifanella, Tempering Kademlia with a robust identity basedsystem, in: IEEE P2P, 2008.

[5] Luca Maria Aiello, Giancarlo Ruffo, Lotusnet: tunable privacy fordistributed online social network services, Comput. Commun. 35 (1)(2012) 75–88.

[6] J. Anderson, J. Bonneau, C. Diaz, F. Stajano, Privacy-enabling socialnetworking over untrusted networks, WOSN, 2009.

[7] R. Baden, A. Bender, N. Spring, B. Bhattacharjee, Daniel Starin,Persona: an online social network with user-defined privacy,SIGCOMM, 2009.

[8] Oleksandr Bodriagov, Sonja Buchegger, P2p social networks withbroadcast encryption protected privacy, in: Privacy and IdentityManagement for Life, Springer, 2012, pp. 197–206.

[9] Dan Boneh, Xavier Boyen, Eu-Jin Goh, Hierarchical identity basedencryption with constant size ciphertext, in: Advances in CryptologyEUROCRYPT 2005, Lecture Notes in Computer Science, vol. 3494,Springer, Berlin Heidelberg, 2005, pp. 440–456.

[10] S. Buchegger, D. Schioberg, L. Vu, A. Datta, Peerson: P2p socialnetworking – early experiences and insights, SNS, 2009.

[11] Meeyoung Cha, Haewoon Kwak, Pablo Rodriguez, Yong-Yeol Ahn,Sue Moon, I tube, you tube, everybody tubes: analyzing the world’slargest user generated content video system, in: IMC, ACM, 2007.

[12] A. Cutillo, R. Molva, T. Strufe, Safebook: feasibility of transitivecooperation for privacy on a decentralized social network.

[13] A. Cutillo, R. Molva, T. Strufe, Safebook: a privacy preserving onlinesocial network leveraging on real-life trust, IEEE Commun. Mag.(2009).

[14] Emiliano De Cristofaro, Mark Manulis, Bertram Poettering, Privatediscovery of common social contacts, Int. J. Inform. Security 12 (1)(2013) 49–65.

[15] Ccile Delerable, Identity-based broadcast encryption with constantsize ciphertexts and private keys, in: Advances in CryptologyASIACRYPT, 2007.

[16] Claudia Diaz, Seda Gürses, Understanding the landscape of privacytechnologies, Extended abstract of invited talk at InformationSecurity Summit, 2012.

[17] Peter Druschel, Antony Rowstron, Past: a large-scale, persistentpeer-to-peer storage utility, in: Hot Topics in Operating Systems,2001.

[18] M. Durr, M. Maier, F. Dorfmeister, Vegas – a secure and privacy-preserving peer-to-peer online social network, in: Privacy, Security,Risk and Trust (PASSAT), 2012, pp. 868–874.

[19] Catherine Dwyer, Starr Roxanne Hiltz, Katia Passerini, Trust andprivacy concern within social networking sites: a comparison offacebook and myspace, in: AMCIS, 2007.


http://www.rechtzweinull.de/archives/840-Zensur-bei-Facebook-Reichweitedes-virtuellen-Hausrechts.html



http://www.mmnews.de/index.php/etc/13534-facebook-zensiert-femen

http://www.mmnews.de/index.php/etc/13534-facebook-zensiert-femen

http://www.reuters.com/article/2007/11/23/us-syria-facebook-idUSOWE37285020071123

http://www.reuters.com/article/2007/11/23/us-syria-facebook-idUSOWE37285020071123



154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626

16271628162916301631163216331634163516361637163816391640164116421643164416451646

1647

16491649

16501651165216531654165516561657

16591659

16601661166216631664166516661667166816691670

16721672

1673167416751676167716781679168016811682168316841685168616871688168916901691169216931694



16 October 2014

Q1

[20] M. Falch, A. Henten, R. Tadayoni, I. Windekilde, Business models insocial networking, in: CMI International Conference – SocialNetworking and Communities, 2009.

[21] Antonino Famulari, Artur Hecker, Mantle: a novel dosn leveragingfree storage and local software, in: ICAIT, 2012.

[22] H. Gao, J. Hu, T. Huang, J. Wang, Y. Chen, The status quo of onlinesocial network security: a survey, IEEE Int. Comput. (2011).

[23] Vipul Goyal, Omkant Pandey, Amit Sahai, Brent waters, Attribute-based encryption for fine-grained access control of encrypted data,in: CCS, 2006.

[24] K. Graffi, S. Podrajanski, P. Mukherjee, A. Kovacevic, R. Sreinmetz, Adistributed platform for multimedia communities, in: Tenth IEEEInternational Symposium on Multimedia (ISM’08).

[25] Benjamin Greschbach, Sonja Buchegger, Friendly surveillance – anew adversary model for privacy in decentralized online socialetworks, in: Current Issues in IT Security, 2012, pp. 195–206.

[26] Benjamin Greschbach, Gunnar Kreitz, Sonja Buchegger, The devil isin the metadata – new privacy challenges in decentralised onlinesocial networks, in: SESOC (PERCOM Workshops), 2012.

[27] Saikat Guha, Kevin Tang, Paul Francis, NOYB: privacy in online socialnetworks, in: First Workshop on Online Social Networks, 2008.

[28] Felix Günther, Mark Manulis, Thorsten Strufe, Cryptographictreatment of private user profiles, in: Financial Cryptography andData Security, Springer, 2012, pp. 40–54.

[29] Sonia Jahid, P Mittal, Nikita Borisov, EASiER: encryption-basedaccess control in social networks with efficient revocation, in:ASIACCS, 2011.

[30] Sonia Jahid, Shirin Nilizadeh, Prateek Mittal, Nikita Borisov, ApuKapadia, Decent: a decentralized architecture for enforcing privacyin online social networks, SESOC (PERCOM Workshops), 2012, pp.326–332.

[31] David Koll, Jun Li, Xiaoming Fu, With a little help from my friends:replica placement in decentralized online social networks, 2013.

[32] M. Kryczka, R. Cuevas, C. Guerrero, A first step towards user assistedonline social networks, SNS, 2010.

[33] D. Liu, A. Shakimov, R. Càceres, A. Varshavsky, L.P. Cox, Confidant:protecting osn data without locking it up, in: Middleware, 2011.

[34] Arvind Narayanan, Vincent Toubiana, Solon Barocas, HelenNissenbaum, Dan Boneh, A critical look at decentralized personaldata architectures. arXiv preprint arXiv:1202.4503, 2012.

[35] Rammohan Narendula, T.G. Papaioannou, Karl Aberer, Adecentralized online social network with efficient user-drivenreplication, in: Enabling Technologies: Infrastructures forCollaborative Enterprises, 2010.

[36] Shirin Nilizadeh, Sonia Jahid, Prateek Mittal, Nikita Borisov, ApuKapadia, Cachet: a decentralized architecture for privacy preservingsocial networking with caching, in: CoNEXT, 2012.

[37] Thomas Paul, Sonja Buchegger, Thorsten Strufe, Decentralizing socialnetworking services, in: International Tyrrhenian Workshop onDigital Communications, 2010.

[38] Thomas Paul, Benjamin Greschbach, Sonja Buchegger, ThorstenStrufe, Exploring decentralization dimensions of social networkservices: adversaries and availability, in: HotSoc (KDD Workshop),2012.

[39] T. Perrin, Public key distribution through ’’cryptoids’’, in: Workshopon New Security Paradigms, 2003, pp. 82–102.

[40] Fatemeh Raji, Ali Miri, Mohammad Davarpanah Jazi, Behzad Malek,Online social network with flexible and dynamic privacy policies, in:CSSE, IEEE, 2011, pp. 135–142.

[41] Antony Rowstron, Peter Druschel, Pastry: scalable, decentralizedobject location, and routing for large-scale peer-to-peer systems,Middleware, 2001.

[42] Amit Sahai, Brent Waters, Fuzzy identity-based encryption, in:Advances in Cryptology EUROCRYPT 2005, Springer, 2005.

[43] Stephan Schulz, Thorsten Strufe, d2 deleting diaspora: practicalattacks for profile discovery and deletion, in: ICC, 2013, pp. 2042–2046.

[44] Lorenz Schwittmann, Christopher Boelmann, Matthaus Wander,Torben Weis, Sonet-privacy and replication in federated onlinesocial networks, in: ICDCSW, Springer, 2013, pp. 51–57.

[45] S. Seong, J. Seo, M. Nasielsky, D. Sengupta, S. Hangal, S.K. Teh, R. Chu,B. Dodson, M.S. Lam, Prpl: a decentralized social networkinginfrastructure, in: Workshop of on Mobile Computing andServices: Social Networks and Beyond, 2010.

[46] Nashid Shahriar, Shihabur Rahman Chowdhury, Mahfuza Sharmin,Reaz Ahmed, Raouf Boutaba, Bertrand Mathieu, Ensuringbeta-availability in p2p social networks, in: ICDCSW, IEEE, 2013,pp. 150–155.


[47] A. Shakimov, A. Varshavsky, L.P. Landon, R. Càceres, Privacy, cost,and availability tradeoffs in decentralized osns, WOSN, 2009.

[48] Rajesh Sharma, Anwitaman Datta, Supernova: super-peers basedarchitecture for decentralized online social networks, in:COMSNETS, IEEE, 2012, pp. 1–10.

[49] Rajesh Sharma, Anwitaman Datta, M. DeH’Amico, Pietro Michiardi,An empirical study of availability in friend-to-friend storagesystems, in: IEEE P2P, IEEE, 2011, pp. 348–351.

[50] Daniel Stutzbach, Reza Rejaie, Understanding churn in peer-to-peernetworks, in: IMC, ACM, 2006, pp. 189–202.

[51] J. Sun, X. Zhu, Y. Fang, A privacy-preserving scheme for online socialnetworks with efficient revocation, in: INFOCOM, 2010.

[52] Florian Tegeler, David Koll, Xiaoming Fu, Gemstone: empoweringdecentralized social networking with high data availability, in:GLOBECOM, IEEE, 2011, pp. 1–6.

[53] A. Tootoonchian, S. Saroiu, Y. Ganjali A. Wolman, Lockr: betterprivacy for social network, CoNEXT, 2009.

[54] C. Wilson, T. Steinbauer, G. Wang, A. Sala, H. Zheng, B.Y. Zhao.Privacy, availability and economics in the polaris mobile socialnetwork, in: HotMobile, 2011.

Thomas Paul is a Ph.D. Student and ResearchEngineer at TU-Darmstadt. He received hisDipl. Wirt.-Inf. degree from TU Ilmenau. Afterspending three years as a business (pricing)consultant, he returned to science. His thesiswill focus on security in Online SocialNetworks.

Antonino Famulari is a Ph.D Student atTelecom ParisTech, affiliated with the doctoralschool in Innovation and Entrepreneurship ofthe EIT. Previously, he obtained his MsC intelecommunication engineering (Pisa) andgained experience in consulting and researchat the Italian National Institute of NuclearPhysics. His thesis will focus on protection ofonline privacy, in particular in Online SocialNetworks and content sharing platforms.

Thorsten Strufe is professor Privacy and ITSecurity at Technische Universität Dresden.His research interests lie in the areas of pri-vacy and resilience, especially in the contextof social networking services and large scaledistributed systems. Recently, he has focusedon studying user behavior and security inOnline Social Networks and possibilities toprovide privacy-preserving and secure socialnetworking services and big data solutions.He was appointed professor for Peer-to-Peernetworks at Technische Universität

Darmstadt, Germany, from 2009 to 2014, and visiting professor forDependable Distributed Systems at University of Mannheim, Germany,throughout 2011. Previously, he took posts as senior researcher at
EURECOM and at TU Ilmenau, working on analysis and the security ofOnline Social Networks, as well as resilient networking. He received hisPhD degree from TU Ilmenau in 2007. His PhD thesis deals with theconstruction of censorship resistant and network efficient overlaytopologies for live multimedia streaming, and means to making themespecially resilient towards both the failure of nodes and DoS attacks.



a survey on decentralized online social networks

Documents