Let's just focus on one thing that many people are used to: the news feed.
Say I want to find out what all my friends are up to lately. Since this information doesn't live in a (more or less) central place any more like it used to on Facebook, I need to go out and contact each node (in an encrypted, secure way) that my friends run/pay to host on an ISP and ask them, what they're up to lately. That information then gets merged by my local node (that I presumably access to view a news stream) and displayed to me.
Isn't that more than a bit inefficient? Hundreds of friends, means hundreds of connections going out, to grab friend updates, each with encryption overhead. And all those nodes have to be up and running of course.
OK, so let's assume your own node is smart enough to cache these updates. Maybe it even gets updates pushed to it when my friends update, so it's not constantly polling all of them in search for updates. That means if my friend withdraws permission to see their updates, I still have access to their cached info local to my own node.
So perhaps there's also a push update system that handles revocation. You remove permissions and send another message to those affected to forget your info. But what if I run a modified node that chooses to ignore this information? The whole thing is open source and anyone can tinker with their node code. Say I friend a malicious entity, decide I don't like them anymore, and take back their access. It could be too late.
See, this is the kind of technical detail I was hoping for. Real life examples and a vague outline of how they're going to tackle them.
Well, that's the problem with having friends. Whenever you let someone get near to you, they could be carrying a hidden microphone and a video camera. And, even if you explicitly tell them that you don't want to be friends with them any more, they'll still remember everything you've told them.
The same issue crops up with email, letters ... hell, every way we've communicated for hundreds or thousands of years: there is no way to revoke access to information once granted, even if access to new information is withheld.
You might as well complain that someone could take screenshots of everything you say that shows up in their news feed.
It seems inneficcient if you think of it in an HTTP way, but technologies like BitTorrent are built on exactly this. I see no reason to cache locally and create the additional privacy issues raised in other threads on this page.
We are 140-character ideas. We are the pictures of your cat. We are blog posts about the economy. We are the collective knowledge that is Wikipedia. The internet is a canvas – of which, we paint broad and fine strokes of our lives with. It is a forward extension of our physical lives; a meta-self comprised of ones and zeros. We are all that is digital: If we weren’t, the internet wouldn’t either.
I assume this is the standard they will use for authentication? What about this encryption business? Do they intend to modify the OpenID protocol to do some sort of challenge/reponse step and exchange keys?
Voice-over IP
I'm at a loss for what this means or how it is important to the project. Are they implementing a specific protocol, using a particular libary, or are they going to attempt rolling their own system?
Distributed Encrypted Backups
Backups of what? Distributed why? How?
Instant Messaging protocol
There are a plethora of existing protocols they could use. Since they haven't specified a particular one, does it mean they haven't decided which one to use yet? Are they planning to build their own "encrypted" protocol? Magic?
UDP integration
Whoa. Integration. With UDP? Mind-blowing. I'm assuming that they'll be building the broad-casting bits of the P2P architecture on UDP. It's what most distributed, encrypted P2P networks do.
Oh right, there are already dozens of them and have been for years. I guess these kids are just too young to remember:
What people here might really wanna know it's that the source code will be released under AGPL (you must let your users download the source of the program they're running).
In my opinion for boosting commercial adoption, a MIT license is truly needed. I know it's not in their interest to do so (they plan to build a wordpress.com-like hosting).
With the AGPL, you have some guarantee that improvements will be given back to the community. So while you're right (some of the incentives are removed), you're wrong (other incentives are added). I bet the net effect will be positive.
The Diaspora guys have missed the problem completely: the issues are not technical ones - the major problems here have been solved.
The issue is UX: Nobody - and certainly not Facebook - has come up with an effective interface that allows us to manage our interactions online with the fidelity that we want. And I doubt that these four kids are going to come up with a spell-binding piece of design that does this. They seem to be Ruby programmers, and certainly not designers - graphical, UX or otherwise if one is to judge by their website.
Far deeper analysis of the problem is needed that the reactionary "Facebook are arseholes, they're acting like a big corporation". The details of how we create multiple online publics[1] for ourselves, how we relate to them, and understand them is key to building any sort of infrastructure to manage those publics. The Diaspora guys seem to be treating this as purely a technical problem, when it most certainly is not.
[1] It's the other side of the coin to having multiple online identities, but to me, makes a bit more sense as a conceptual model for what we're dealing with.
Wouldn't it suck if you were some kid with a lot of ambition, and some huge ideas, who tried to bite off more than he or she could handle, all while the world watched and encouraged you? Wouldn't it suck if you felt a real obligation to see through to some half-baked idea you came up with in your early 20s?
I have sympathy for the Diaspora guys, I think if it went unnoticed and unfunded it could be a great learning project for some young coders, even if it didn't achieve practical success. Instead, it'll likely be (already is) a public embarrassment.
If I could give the Diaspora guys one bit of advice, I'd say this, don't take this too seriously; treat it like a fun summer project. The last thing you want to be is the next freenet (no offense Freenet guys, awesome concept, but it never really caught on).
Here's the question I'm left with which has no answer on the site: how will a distributed social network keep my private data private?
I understand how one can build secure communications. That part is easy. So, I have a Diaspora account with "Awesomea" and you have a Diaspora account with "Crapula". It's easy to have communications between Awesomea and Crapula be secure. However, when you visit your Crapula page, you want to see my updates which means that Crapula needs to be able to decrypt my updates. Even if you have a different key for each user (ala public key encryption), for wide adoption the service providers (in this case, Awesomea and Crapula) need to be able to encrypt and decrypt that information (which means they hold the keys).
So, if I friend you and you're using Crapula, I need to trust both you and Crapula that you won't do bad things with my data.
Part of this is that the Diaspora project doesn't seem to have any technical information. They have lofty goals like, "you own your social graph, you have access to your information however you want, whenever you want, and you have full control of your online identity." However, they have scant information on how they plan to accomplish that. They say they're using GPG, but are they going to have a browser plugin with locally stored keys to decrypt the information? That's the only way I can see this being secure. If you're storing your key with Crapula and it's decrypting my information, it can store is as well as show it to you.
Even if the design is to use locally stored keys, what's to stop a provider from offering a "better" (better, in this case, means easier for non-tech-inclined users) Diaspora-compatible server which stores them on the server? And then I have to audit my friend requests to see how their server has set up security?
It's kinda like handing a friend a classified document and a photocopier. You tell them "please don't copy this" and they probably won't. But in this case you're handing that classified document to Crapula and saying "pass this along to my friend and don't copy it along the way". Yes, Facebook has that ability too, but it's one company that has a reputation to defend (to an extent) as well as a legal presence in the United States (which is good for me as a US citizen) and by posting in the first place I'm trusting them with that data. With Diaspora, I could start getting friend requests from all sorts of services run by people a lot shadier than the Facebook folk and I now have to deal with dozens of privacy policies rather than one.
BTW, this is probably the comment that I would most like to be proved wrong on. I want distributed, secure social networking that puts me in control of my data. It's just that I don't see how it works and the Diaspora website doesn't have any information on it either. If someone here knows how this will work, I'd love it! It's an exciting prospect, but I feel like it's the same as DRM: if people can read it/see it/hear it, it can be copied. Likewise, if a service provider is printing it on screen for one of their users, they can store it. If anyone has technical information on how this works, it would be really awesome!
Seconded. Also, the answer to the second question ("is Diaspora portable") dodges the actual question, and makes me wonder what the Diaspora team actually want to accomplish. An answer like "portability is not an issue, we plan to sell you fully configured plug computers anyway" would be much more reassuring.
I suspect they don't plan to sell such devices. And I totally don't understand why not.
Of course you can't prevent people from copying stuff. But you can control who you want to trust. If the interface allows easily grouping people, you can easily publish your political thoughts with your friends and your children photos with your family. Everything else is not a technical problem: before you tell someone something confidential, you'll gauge wether she will repeat it to everyone and to whom she might repeat it.
The point of my post wasn't to bring up the issue of how to gauge whether friends will repeat/copy things. The issue is that Diaspora is bringing in another layer to the mix: third-party service providers. Right now, with Facebook, I have to judge whether I want to share something with you. With Diaspora, I'd have to judge whether I want to share something with you and whether I trust your service provider to be a trustworthy go-between.
With Facebook, I have to read and agree to a single privacy policy. With Diaspora, I might have dozens (or more) policies that I'd have to read and track (if I care about privacy). Diaspora seems to say that I don't have to trust the other service providers. They're saying it's "privacy aware, personally controlled". They say that their "current implementations include GPG encryption". They say that "Diaspora knows how to securely share (using GPG) your pictures, videos, and more," and that, "When you have a Diaspora seed of your own, you own your social graph, you have access to your information however you want, whenever you want, and you have full control of your online identity."
But how is that? I don't expect them to fix the issue of one of my friends using cut and paste. However, they are claiming that I'm in control of my data. If other sites are able to decrypt that data, then those other sites will be able to store that data. How are they getting around that?
From my perspective, Diaspora is adding more privacy concerns since I now have to decide whether I trust my friends and my friends' service providers rather than just Facebook and my friends. It isn't just whether a company is going to be evil. Sometimes companies accidentally expose data and sometimes companies are breached.
Diaspora's grandiose statements seem to promise end-to-end security; that none of the servers between me and my friend will be able to decrypt the data. They claim that I'm in control of my online identity making it seem like if I delete something off of my Diaspora account on one provider, it will be removed from the feeds on other providers.
But I can't see a way that this would work. If I have a Diaspora server with you as a user and I go to get your friends' status updates from other Diaspora servers, isn't my server going to be able to decrypt that information in order to pass it along to you as text? You've elected to trust me with your information, but have your friends? Couldn't I store their status messages against their will? Couldn't I make them public against their will?
What I'm looking for is someone to tell me how Diaspora is going to keep my information private. Yes, I could decide which service providers to trust and weed my friends based on that, but that isn't the security that Diaspora is claiming. They're claiming that they're privacy aware, that I'm in control of my data, that it's being securely shared, that I'm in charge of my social graph and online identity. I just don't see how they're accomplishing it and their site offers no information on how.
Here's the base issue: I post a status update. Your service provider has gotten it from mine and put it in your feed. I delete it. Does your service provider just voluntarily remove it on their end? I don't want it there, but there's nothing I can do about it beyond appealing to their good graces. That isn't putting me in charge. If I'm to be in charge, when I delete that post, you have no more access to it (unless you used copy/paste or something else) and your service provider no longer has it in their database. Diaspora hasn't said how they're going to accomplish this. In fact, deleted posts would be the best thing to data-mine: they're things people don't want shared because they're embarrassing or whatnot. Think about it, you tag a photo of me and that gets cached by service providers. I do a remove-tag request on that photo - that's likely a photo I don't want people seeing. That remove-tag request gets propagated out, but rather than removing the tag, some service providers just put a date_to on the tag, others might just ignore it completely. I'm not in control of my data there. How is Diaspora getting around this problem (since they claim to be)?
You speak exactly of the problem: Having outside service providers. When you have an outside service provider you are now, and will always be, dependent upon the service provider. The only solution is to not use service providers and to distribute your own data (as you have described). When you distribute your own data, you can have nightly encryption key updates sent to all of the friends you trust. If you remove a friend from your list, they do not get the nightly key update and no longer have access to your information. What I describe in my article that I published on Saturday is that we are not at the point yet where completely distributing all of your own content created by you is plausible. The use of third party "service" providers is simply a necessary (for some people) thing in this transition period.
Nothing will give you definitive answers: email is decentralized but computer-litterate and privacy-aware people use gmail and regularly send important emails to gmail users...
I agree with you that there should be some way to "quite easily" encrypt everything so that your recipient decrypts it only on its client software, though I doubt the situation will differ from the current one with emails. But "Freedom" lies in the effective ability to use it. Once all protocols are open your issue is more social than technical: for this see Elben Moglen's ideas on personal servers (tiny pluggable servers…) (even if we already have DSL boxes and even phones for small-bandwith data).
Ok now take this whole bunch of salt, because I have no idea what Diaspora is planning, but another model might be more like p2p.
So there are no accounts with Awesomea or Crapula. Instead you have the diaspora software running on your own machine. Now Awesomea and Crapula have some social aspects on their site - for instance they want to send an update to your friends. So Awesomea and Crapula sends a request to your ip on the Diaspora port which includes the update message. Its now up to your computer to distribute that message to your friends, and Awesomea and Crapula have no idea who those people are.
Of course you'd probably want the diaspora software hosted externally, but the model could still mostly be the same. Now if Awesomea or Crapula need to compute something using private data, I don't know what happens, perhaps they can provide logic to be run in a diaspora sandbox somehow.
The big issue with client side decryption (which sounds like a must if you don't trust all the nodes) is that brute force password guessing turns from almost impossible to extremely simple since it's done offline.
Because the code is deployed as a network service, if you make changes to the source code (probably to be a better service provider than others), you have to publish your modifications.
Suppose you implement a system based on Diaspora, the next generation of population and governments will use everyday.
For various reasons, such as some of the DoD prototype implementations (classified ones), you don't want, or you're required by law to restrict.
As you implement the "next-generation system" you don't want the Diaspora guys to take your hard work and make profit of it, distrupting you immediately, because you just started (who are advantaged because they were the first ones, it's a bit like a monopoly, (if you can't see it, try to start a "one-click" hosting for wordpress, after they switch to AGPL)). [1]
The other reason is that, such a system is indispensable to this future to work. You would be required by gov law to classify all of your platform (there would be military guards at your data centers :P).
edit
[1] My point is that they're trenched in their market (the first one should be hosting for Diaspora). Think of it this way, all the people who donated, helped in the process of monopolization of a product they were told would be open (the code yes, but the product it's not).
(1) The DoD making sensitive software communicate with the global internet seems unlikely. And if they stick to private networks, the AGPL doesn't get in their way.
(2) I personally won't cry over lost monopolies. Your point was valid, though.
You might very well trust your 'Crapula' provider, and its policies, not to abuse info intended just for you even if they see it in cleartext. (If people really care about these things, Crapula might compete with other providers on the basis of its privacy protection.)
But, for the truly paranoid, it's theoretically possible (though not very usable/comprehensible) for profile/status information to only be decrypted in end-user's browsers.
The old Groove Networks product made a lot of similar promises about peer-to-peer security; if Groove published reusable details of their approach Diaspora might want to check that out. (OTOH, it's now part of MSFT and might be a patent-thicket.)
I realize you're being sarcastic and this doesn't apply to you directly, but this has been bugging me for a while:
Everyone needs to stop saying these guys are "well funded." $200k is nothing especially for a team of 4 people. It's certainly not enough for them to hire anyone else full time to join them. Yes, they didn't have to do much to get this money and I realize it's infuriating if you're really struggling to get your business off the ground when 4 nobodies get a chunk of money out of nowhere, but please recognize that the amount is so small that it doesn't warrant outrage.
Furthermore, they didn't even ask for that much. It got a big network effect in light of the recent facebook privacy issues, but it's a one time thing and most likely the last money they'll ever see for this project. I don't think their situation is repeatable in any sort of predictable way, so it probably doesn't warrant studying (please correct me if someone's figured out a way to do this, cause I think most of us would like to figure out how to get free funding). We should wish them the best of luck and only care when they make something people want to use.
I can already see the headlines of outrage when they don't produce something that destroys facebook overnight, or maybe don't release on time, or their code is really bad. Anyone who contributed to them only expected to give facebook a little jab. There are reasons to question their abilities, but jealousy over their gimmicky funding really needs to stop.
I don't think it's jealously over gimmicky funding, I think it's more along the lines of all this hype was raised, all this money was raised and we're still sitting here, sucking our thumbs to see what's supposed to happen.
The launch date is in September, and so far the last update since the NY Times article was a redesign. The only technical information is that it's using Ruby, "a little bit of rails" and some "other" frameworks.
This feels to me like giving a kid $0.25 for a glass of lemonade, and him telling me he'll bring it to my house after he's built his lemonade stand, bought the ingredients and actually produced a beverage.
This feels to me like giving a kid $0.25 for a glass of lemonade, and him telling me he'll bring it to my house after he's built his lemonade stand, bought the ingredients and actually produced a beverage.
This is exactly the state of the project unless there is a whole lot that the Diaspora team has not publicly documented.
But, as far as I know, they have never stated that this was not the case. Their video made it pretty apparent they had yet to build the lemonade stand and buy the ingredients.
I'm perfectly okay with them being fairly scarce with information until they have something built.
They surely have high caliber advisers at this point. The peanut gallery probably wouldn't be all that helpful as they try to lay the first foundations.
Once there's something complete to react to and build on, they'll release the code.
Google doesn't validate because they need to serve the page millions of times a day. Hacker News is not a startup, it wasn't funded with $200,000, and its goal is not to create a web application (Diaspora's is.)
> Hacker News is not a startup, it wasn't funded with $200,000, and its goal is not to create a web application (Diaspora's is.)
I'm confused. So does anything that is not a start-up, and/or web application get a free pass on standards compliance? I was under the impression that the standards were meant to apply to all web pages.
Say I want to find out what all my friends are up to lately. Since this information doesn't live in a (more or less) central place any more like it used to on Facebook, I need to go out and contact each node (in an encrypted, secure way) that my friends run/pay to host on an ISP and ask them, what they're up to lately. That information then gets merged by my local node (that I presumably access to view a news stream) and displayed to me.
Isn't that more than a bit inefficient? Hundreds of friends, means hundreds of connections going out, to grab friend updates, each with encryption overhead. And all those nodes have to be up and running of course.
OK, so let's assume your own node is smart enough to cache these updates. Maybe it even gets updates pushed to it when my friends update, so it's not constantly polling all of them in search for updates. That means if my friend withdraws permission to see their updates, I still have access to their cached info local to my own node.
So perhaps there's also a push update system that handles revocation. You remove permissions and send another message to those affected to forget your info. But what if I run a modified node that chooses to ignore this information? The whole thing is open source and anyone can tinker with their node code. Say I friend a malicious entity, decide I don't like them anymore, and take back their access. It could be too late.
See, this is the kind of technical detail I was hoping for. Real life examples and a vague outline of how they're going to tackle them.