SECURE SHARE

SECURE SHARE

Why are we still using insecure channels of communication, like e-mail, Skype, IRC and Facebook? Why do we entrust central authorities with our most private data and why do we rely on their infrastructure?

Because there isn't an easy to use alternative yet!

End-to-end encryption and decentralized social interaction is always a hassle. Our goal is to give developers an easy to use framework that hides the complexity of decentralized message passing, a distributed social graph and naturally embeds encryption.

We hope to encourage the development of interfaces and platforms that are as user friendly as they can be. In the end, a distributed social platform can only succeed if everyone uses it.

The network we are currently bootstrapping will enjoy the speed of servers that help without knowing much about us, the trust of social relationships between users without becoming transparent, the privacy of elaborate obfuscation strategies without becoming unpractical.

This way, we can become independent of centralized infrastructure and rest assured that no one but the designated recipients can read our communications.

We employ GNUnet for peer-to-peer routing and encryption and PSYC to create the social trust graph (because it performs a dozen times better than XMPP or OStatus).

Radical Privacy is barely enough

We call this "Secure Share," a framework for sufficiently safe social interaction. It arose after realizing that there is no satisfying technology to address the issues we outlined in the FSW 2011 paper entitled "Scalability & Paranoia in a Decentralized Social Network." Here's what we mean by safe:

  1. updates, comments, postings, messages, files and chat are only visible to the intended recipients (not the administrators of any servers or routers)
  2. the type and content of a message cannot be guessed at by looking at its size
  3. communication between parties cannot be measured as they may have none to several routing hops in-between. an observer never knows if a communication came where it came from and ends where it is going to.
  4. automatic responses and forwarded messages can intentionally be delayed so that an observer cannot tell two communications are related
  5. communications cannot be decrypted weeks later, just because the attacker gained access to one of the involved private keys (forward secrecy)
  6. even if an attacker gains access to a cleartext log, there is no proof the material was actually ever transmitted by anyone (for a case in court mere data would not suffice, you need actual testimonies)
  7. the list of contacts is never managed on potentially unsafe servers, it is only visible to those it should be visible to
  8. the infrastructure is robust and resilient against attacks

And if you are happy with less than that, we want you to just pull that slider from 'safety' towards 'convenience' on your own responsibility. You no longer need to switch software to pass from one to the other mode of operation.

As we researched in the paper and in further detail in the comparison only some advanced anonymization and P2P file sharing applications have explored these levels of privacy. So we decided to take one such technology and subvert it by applying our social information to it.

New materials

Buzzwords to Dig Into

  • Answers - Some FAQs asked and answered.
  • Architecture - How does it stand tall?
  • Business - Capitalism in the darknet.
  • Censorship - We do ad-hoc mesh networks, too.
  • Comparison - Is there any alternative really?
  • Conspiracy - What if everyone is out to get you.
  • Features - How hard would it be to be like Facebook once was.
  • Federation - Why the decentralized social web thing doesn't work.
  • Like - Let us have a distributed Like button, please!!
  • PGP - A number of reasons not to start using it.
  • Privacy - If you have no secrets, you have no life.
  • Protocol - Ingredients: Efficiency and extensibility.
  • Prototype - Current status of the prototype version.
  • PubSub - The publish and subscribe paradigm revamped.
  • Rendezvous - How to get started when you know nobody.
  • Rights - You don't need a Bill Of Rights from us. You own us.
  • Scalability - Multicasting, the key to make applications work for billions.
  • Storage - About the new civil right for data deletion.
  • Threats - What if malware messes up your secushare identity?

Events and Press Coverage

Social network services have gained widespread use world-wide and by very different people. To compare the currently most important social network services, six self-selected use cases and an accompanying user survey were conducted. Comparison and survey confirm that the large commercial providers offer sufficient functionality, but lack in the areas of security, privacy and provider independence. In a world under surveillance, most social network services are not suitable for sensitive personal data. It is shown how the architecture of a system affects the business model of the provider and the possibilities for self-determination and freedom of users. Two social network services currently in development, Briar and Secushare, are presented in more detail, followed by an explaination of technical challenges in P2P-based systems.

Projects that have already expressed interest in this technology

Source Repositories

This is a free software project, since the kind of security we want to give to people can only be credible and trustworthy if it is freely available in its entirety and can be converted to machine executable programs by as many independent persons as possible.

Components of the system are built using the GNUnet framework. The design is described in "Design of a Social Messaging System Using Stateful Multicast". Current development is going on in

  • the SVN repository of GNUnet (look at the psyc, psycstore, multicast and social directories).
  • UI prototypes currently reside in gnunet-qt.

As the architecture page explains in detail, we don't use GNUnet for file sharing, so you don't need neither a particularely large hard disk nor a lot of bandwidth.

How can you help?

  • You can express your support for us. (example)
  • You can help us get funding, help us with our communications, work out alliances or simply give us more visibility.
  • You can give us feedback if you think we are designing the perfect tool everyone has been waiting for, or if there's anything we overlooked.
  • If you're a web designer, you can help us get a cross-device user interface going as described in architecture.
  • If you're a graphics artist, you can spice us up.
  • If you're a lawyer.
  • If you're a C developer, talk to us to help us with the core service.
  • If you're a developer in whatever other technology you like, you can design or translate a wide choice of tools (see 'Native User Interfaces' in architecture for examples) to work on top of Secure Share.

And, in any case, if you like what you see here, you can consider diverging some funds in our direction.

P2P Compliance

Secure Share is supposed to fulfil the following requirements for true P2P:

Oh, by the way, did I mention that Secure Share also runs over ad-hoc mesh networks?

Questions?

Here are some answers, or try our welcome chatroom:

Stay in Touch

Drop your email address into these boxes, then hit each button to subscribe each of the following lists:

to the discussion list
to the developer list
to announcements only

We don't recommend it, but you can follow us on Twitter.

Top