If I want to change my email address? Change it in one place. If I want to let my friends know something? Update it in one place. It's very DRY you know?

But then I think, why even let Facebook use my data? If we have these data stores let's build a peer to peer network to let trusted friends access our information. In real life, if I want to tell my friend something I don't pass it through a 3rd party first, I tell them directly! This can let us have really fine grained control over who we share with by authenticating the users that request the information. And with the authentication can come encryption.

This move to the cloud is, frankly, annoying. Why should we have to trust our data to all these people we don't know? They pretend that they give us "free" service, while actually using that data for profit. Good UI shouldn't have to come at such a cost.

I have been thinking about this for a while, if there are other people interested in building such a web I would love to know.

1.) Go to web page and use application, or 2.) Download app and use application

This is how Facebook / Twitter / etc. do it., and they're clearly doing it right. But there's no law which says that the application needs to keep its data on a third-party server. Why not have it run a Peer-to-peer service?

In fact, I think that Peer-to-peer is especially suitable to social networking, given that social networks are typically highly clustered (eg., people who are my friends are much more likely to be each others' friends as well). This means that if the every client application is able to redistribute copies of friends' status updates as well as its own status updates, then a sync between any given pair of clients is likely to allow them to bring a large subset of their friends' statuses up to date.

Of course if you're rebroadcasting your friends' status updates as a P2P host, then the question of spoofing/authentication becomes paramount. Obviously that would have to be solved by having all status updates transmitted in encrypted formats which can only be decrypted / authenticated with a users' public key.

Oh, and once you've got dual-key authentication embedded in widely-used social trust networks, you could probably solve a lot of other authentication problems while you're at it.

All of this would need to be completely transparent to the user, of course. If it's any more difficult to set up and use than standard Facebook / Twitter, it will fail. But I don't see any fundamental obstacles to making it that easy.

Unfortunately I don't have time to do anything about this!

As much as I would love to use and have a network like this, until all the people I keep in touch with through facebook use it, I'll still have a facebook.

I wonder if it's plausible, even possible, to have all those p2p benefits (encryption, authentication, privacy) and some how also have interoperability with facebook?

FB and Twitter have APIs. Of course, they can revoke your key. But they have web clients, so they can be scraped.

Faced with a genuinely distributed opponent, there's no way the existing behemoths can keep your data in their silos.

For instance, FB can block tent.is at the API level or even at the IP level. But if Tent hosts pop up all around the internets, and if they are general-purpose enough that users can install their own scraping gateways, which can't be attacked centrally using technical or legal means... it's game over. To me this is one of the less recognized advantages of a distributed service.

Maxim.

That is the goal of unhosted. http://unhosted.org/ I really whish their RemoteStorage protocol would gain traction.

The locker project is heading into the same direction, although with a different approach. Posting content to Facebook et al and then recollecting it into your locker. http://www.lockerproject.org/

Granted, the issue can be mitigated with trust networks, social conventions, or laws, but it comes down the same issues faced by DRM media formats: if someone can consume the content, they can find a way to duplicate the content.

Using known cryptographic methods, we can construct a system that works as follows:

1) Alice looks up Bob's public key (or gets it from Bob to avoid needing a trusted key service) 2) Using Bob's public key, Alice encrypts a message 3) Alice sends the encrypted message into the network, addressed to Bob 4) Using his private key, Bob decrypts the message

In the second example, the recipient (Bob) is the only one who can release the data. In the first example, a number of potentially malicious parties have access to the data without corporation from Alice or Bob.

I used a direct message for simplicity, but we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it.

This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo.

In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does.

That particular photo, yes. But Bob could also have saved that photo as soon as he saw it or maybe he's got eidetic memory, so crypto can't help with that anymore.

However, any new photos shared through the same channel can't be seen by Bob anymore because I assume the key changes as the members of the access group change.

Still, while you can't solve the original problem (Bob can leak everything), you can still do slightly better than that by properly implementing Off-The-Record messaging[1]. This adds perfect forward secrecy, as well as deniability: The latter is very interesting because in OTR it means that both parties can authenticate received messages to be certain of the sender's identity, but they can also FORGE any message to look like it's been signed by the other. This means that even if Bob decides to publish your private messages to him, he can never prove you were the one that wrote and signed them, because he could have forged them himself.

Two problems with that: I'm not sure how the OTR protocol extends to multiple recipients (but I bet there's some research on it), and while this "deniability" might be enough for private (text) messages, it's not much use for photographs in many cases: If Bob decides to publish an embarassing photo of you that he had once access to, it's not going to be much use that you can argue "ha, but you can't prove I sent you that photo!".

Still, for textual communication, it adds a (thin) layer of extra security even though you can never beat Eidetic Bob.

[1] http://www.cypherpunks.ca/otr/index.php#docs and in particular http://www.cypherpunks.ca/otr/otr-codecon.pdf

OTR is pointless for a medium that's mostly about photo sharing. For the Facebook use case, what's far more important than crypto is the set of social norms the site establishes via what's easy to do (share) and what's hard, e.g., archiving everything your friends share as it comes in. Not only would that be tricky to do without getting detected as a bot, but 99.9% of users would never think to try it. This problem is inherently more tractable with a distributed system, and that could be bad.

Actually, facebook does, and that information is (potentially) available to third parties. The intent of my system is that in order for information to leek, you would need to have one of your trusted recipients be compromised.

For the rest of us, though, someone we unfriend (an ex-partner, for example) being able to archive and still access all of our old photos/updates is a much bigger concern. I argue that distributed social software should follow Facebook's lead and offer a sane default of not having such an archiving feature, and not going out of its way to make it particularly easy to add one, either. Otherwise the "creepy" aspect of not being able to rescind access to your photos/updates is going to be a serious downside to this new network, and could keep people from using it.

Edited to add:

Also, what's more secure in theory isn't always more secure in practice. Moxie Marlinspike observed that the original version of Cryptocat (which did end-to-end encryption in JS) was potentially less safe than Gchat. Why? Because if you compromised Cryptocat's server, you could make it serve JS with a hidden backdoor. And Cryptocat, being a one-man shop, would likely be a softer target than a company like Google, which has had plenty of time and expertise hardening their systems. How much do you trust the guy behind Cryptocat, versus Google with their reputation to protect?

Along the same lines, imagine you use a hosted Tent server for social networking — you don't have time to bother running your own server, but you've heard Tent keeps your data safe from Facebook, so it'll protect your privacy better, right? But then the random guy hosting your Tent account turns around and leaks your info. Or he's running old software with a vulnerability in it, and gets pwned. Suddenly hackers have all your data. Would that have happened on Facebook?

When I was curious about signing up with Diaspora, one of the open community pods had a cheeky note from the server admin saying basically that he would peek in and read your stuff if he felt like it. So this is not entirely hypothetical. I'm a huge fan of efforts like Tent, but let's not forget there are upsides to Facebook and Google's stewardship, and an alternative system can easily have as many privacy/security cons as it does pros. Tread carefully.

I guess the deniability part is sort of out the window, seeing as how facebook will be logging the traffic pattern(s) -- but you might at least claim that "no, that wasn't what I said".

Because you shouldn't be trying to close the analog hole, it's essentially impossible (just look at sites like failbook).

Instead you should be trying to be about as secure as email, and allow other people to secure it if that's what they want to try and do.

Operating with these assumptions means that the things that you make public are totally and incontrovertibly public. It is, in a manner of speaking, playing for keeps.

Isn't Twitter the same though? Deleted tweet's have a way of staying around... :P

Why not, it will go to that point.