Diaspora Security - will this work? | Hacker News Reader

Diaspora Security - will this work?

github.com

17 pointskuahyeow18 comments

Diagram Why have a secure client and web browser? Why wouldn't both interfaces only be via the web and secured with TLS? Doesn't the local "secure" client provide a backdoor and increase attack surface? I could understand an out or band channel eg a management interface or SMS for two factor authentication and out of band messaging. I'm not sure that in social networking adding client into the permissions for Data, Posts and Comments make much sense

What interface is the seeds outside the pod communicating on? Should in not be via the web or secure interface? Or is this another API for seeds in different pods to communicate?

Why is there a database per pod?

Think the goal of encrypting only sensitive data and depending on the users risk appetite makes sense but it is not compatible with your low complexity goal. Also it is harder to explain to users and when security is left unto users in practice the lowest or default security option generally gets chosen. So this may work if encrypted and no access is the default

Minor point - why invent aspect when group works?

The security model looks like standard mandatory access control. I'm not sure this works well in social networking. A better model maybe discretionary access control with inheritance of permissions and management by Aspect, Audience and User. Permissions should be able to be granted or revoked at the Data, Post and Comment level

"Dual authentication is required. Users authenticate via a login name and password." If by duel authentication you mean two factor, this does not achieve that.

"Audience Seeds must request the Post and any encryption key from the Owner Seed." This sounds like manual key exchange, a better approach maybe any posts to an Audience is encrypted to the public keys of all members, so when the notification is received posts can be automatically decrypted by the private key of each Audience member

"However, this has the ramification that any change in Audience of a Post would also change the Audience of any Comments by other Users. This would suggest that Audience changes should not be allowed, but a easy method for enforcing this is not evident" You could let each Owner who comments change the access level of their comment. If this is set to a higher level than the post the comment is not visible to the additional audience

I would also be interested in the high level requirements that drove this architecture eg for a secure distributed social network some basic requirements I would have thought are: [+] least privilege access to data posts and comments based on explicitly authorized access for the audience set by the data owner. [+] the most restrictive permissions set by a owner, aspect or audience of the data to apply [+] secure in transit all data [+] secure in storage and backup unless owner sets as insecure [+] access to all data shall be authenticated and authorised and limited to least privilege on each access request for data (a vulnerability in the first release where simply by changing user ID other users content could be accessed [+] authentication and authorisation shall be based on open standards and federated eg open ID and oAuth [+] Multi factor authentication shall e supported [+] Sharing of of Data and access to functions with authenticated users, aspects and audiences shall be simple [+] Access granted to Audiences and Aspects shall be inherited by users belonging to those [+] Ideally the creation of Aspects and Audiences shall be self forming based e.g. on algorithmic analysis of common interests and existing connections

I think a pod is a host, like wordpress.com is a host of WP blogs, hence a database per pod. A seed is an individual user account. The way I understand it, each seed can be encrypted so that even the pod owner can just look in the database.

The really interesting bit comes from key and information exchange between seeds. I agree it's going to be hard to explain all this succinctly to users. Theoretically, the goal is secure and decentralized social networking. One use case would say, a friend on another host can see your photos, but no one else on that other host. Can this ever be done in a foolproof and secure way? I can think of a lot of different things that can fail - malicious impostors, users setting the loosest security, revocation, but it might be good enough for a vast majority of users.

If it works as I think is described in the high security model, you will have to upload a copy of your update for every single friend. And when you add a new friend, you will either have to reupload all the old posts or your new friend will be presented with a blank profile.

And if it doesn't work like that, there's not much difference between low and high security that I can see.

You can reduce this workload by using an asymmetric algorithm like RSA to store an intermediate key.

Post = P Symmetric encryption of X with key Y = E(X, Y)

Posts are stored as E(P, K_master) Authorizations to posts are stored as E(K_master, K_reader)

You can trust your friends (that don't own quantum computers) with your RSA public key, allowing them to E(K_master, K_you) data that can only be decrypted with your private key.

It is weak to a known plaintext attack (in which a user Eve with both K_master and E(K_master, K_alice) could attack Alice's private key), and of course weak to an authorized user sharing the master key. It's also weak to copy and paste, just like every other private social network.

I assumed you would at least want to block people leaking the master key, even if you can't stop copy paste.

Since it's only for that particular item, it doesn't offer any reason to leak it and not just the item content.

All this high-level stuff is great and all, but honestly, after that developer "preview" release, I am extremely nervous about putting any personal info on a seed (or whatever they call it).

I feel that they've lost a lot of trust, and they will need to do something more than a super high-level wiki page on github to win this trust back.

Don't spread FUD. These guys are at least trying to do something in a market where almost everyone else has assumed Facebook has won. And they built and shipped something. I can't even remember the last time I could claim that 100%. Finalize your opinion when their final release is available.

I'm curious -- what is your faith in them based on? I feel sorry for the amount of expectations they were shouldering, but are you being supportive because you truly believe in their (unproven) technical abilities, because you hate Facebook so much, or are you just being nice because startup criticism can be really soul-killing? If a large corporation had released alpha code like that, would you trust the corporation with your data, even down the line? As much as it may be a nice Don Quixote story, results and credibility are the only things that matter here. The four of them are probably wonderful people, but that means squat when it boils down to code.

Faith? Support? I certainly don't have faith in them any more than I have faith in you. I know neither you nor them. How could I have "faith" in an unknown? However, I believe that most of the time people attempt to be good. And given that they are willing to let us see their code (unlike many other institutions) I would argue they are living up to my belief at least for now. So they released an alpha that had security issues? The model of open source validated itself; they received critical feedback and will hopefully act on it. If they do not act on it, so be it, I will not trust them with my information. But I don't believe in cynicism especially cynicism aimed at a self-advertised alpha project.

Does that mean I support them? Very well then, I support them! Go hunt some giants! Change the world! Go make things better while your critics sit on their hands and tell you can't, too afraid to build things themselves!

Being good and being able to write secure software are very different, somewhat orthogonal, qualities.

If a large corporation had released alpha code like that, would you trust the corporation with your data, even down the line?

Have no misgivings: Facebook has exactly the same kinds of buggy messes while features are in development. The only difference here is that Facebook's prototypes never see the light of day, whereas Diaspora's did.

Do you use Facebook on a regular basis? Things are better now but 6 months ago I wouldn't consider that statement to be accurate. I'd consider a Win98 system as reliable as Facebook was then.

"These guys are at least trying to do something in a market where almost everyone else has assumed Facebook has won."

Considering they were pretty much given $200,000 via a site which NEVER allows startups on their site (what does Diaspora have to do with the creative arts again?), and widely promoted themselves via mainstream media sources without even having written a line of code, I don't think it's unfair to have extremely high expectations from the get go. It's not like it's some random bunch of guys who posted stuff in progress on HN.

The truth is, I want them to succeed. They may not defeat FB, but perhaps they'll give us a legit alternative.

And yes, I understand that it was a developer release, pre-alpha, or whatever you want to call it, but a release is a release and it people will form opinions of the software because of it. Remember KDE 4.0? It was unusable but it was released, and a lot of controversy and annoyance came out of it. Remember Netscape's brilliant idea of letting real users be its "beta testers"? That was a bad idea.

It doesn't matter what you tag a release as; a buggy release is a buggy release.

I will look at the next stable release with an open mind, but there is no reason for me to blindly discard their past.

They're doing a difficult thing by making an effort to share progress as it happens in a transparent way, and I think that deserves a lot of credit. They never said they would be the anti-Facebook, they never said it would be perfect, and they're working on a solution to a very complex problem.

To be fair, I think you're mixing "trust" and "hope" and in that sense they've only lost a lot because an unjustifiably large amount of hope was placed in them from the get go.

Personally, I trust that they can still produce a solid security model. A non-beta release can hardly be judged from a final verdict perspective, even or maybe even especially from a security standpoint.

It seems kind of hand-wavy in parts. Looking at the Seed-to-Seed communications this part doesn't seem too well thought through: Note - Audience authentication may be required to reduce the load of serving requests from non Audience Seeds.

What does the audience authenticate to? The origin or the serving seed?

How is revocation handled?

When person A comments on person B's item, who gets to decide who sees that comment?

Reply on news.ycombinator.com