Encryption in Diaspora

Development
1

One thing which has always been in the background in Diaspora but rarely seems to make it to the foreground. (Of course, there might be much discussion and development around encryption in the background, but I’m not aware of it.)

In a decentralised network, the existence of many pods run by many different people is one potential source of weakness from the point of view of data security. So far a lot of this seems to be taken on trust that no podmin is going to abuse the trust placed in them. (I raised two years ago the possibility of criminal gangs setting up rogue pods in order to harvest user data, and was told it was fine because all the podmins were really groovey people. That’s fine in a tiny start-up, but as the network grows in size, it will become a more attractive target.)

I imagine encryption will include:

  • encryption of data stored on a pod
  • encryption of communications between pods
  • encryption of notifications (emails and others)
  • encryption of any chat/VoIP services built in
  • encryption of data exported/imported as part of account migration
  • and possibly others.

(The chat and migration ones are, I think, being dealt with on the discussions for those issues.)

As encryption is likely to become a more pressing issue as the network grows, and an attack of some sort becomes slowly more likely, I thought it would be a good time to start discussing the issue: whether it is really necessary (I think it is, but I may be wrong); what sorts of encryption are needed, and in what areas; what would be the best approach to use in Diaspora, and how to go about implementing it.

I suspect this is going to be one of those topics which require a lot of thought and a lot of work, so I propose setting up a working group dedicate to looking into this issue and reporting back, in the way L3MNcakes has proposed on this discussion on federation, if it is considered an issue that needs looking into at this time.

Of course, it’s easy for me to say, as I don’t have the technical expertise to actually be involved in working for this! But I’ll do what I can to help. With this big and important issues, such as encryption, federation and so on, I suggest we use the DHQ account and other means open to us to advertise for people to take part in these crucial and large projects.

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

I think Diasporas mode, encrypting the transport, is fine for what Diaspora is.

Diaspora is not for providing a ultimately secure communication channel. If you need that you’re better off with things like PGP or OTR/OMEMO. Diaspora is about taking your data from cooperation, ensuring its value isn’t exploited without you noticing.

Full and secure storage encryption simply isn’t possible with Diasporas current model, without limiting the user experience a lot, at least. While you can encrypt all data with a private key that’s encrypted by the users password and blablabla… that’s simply wasted resources. If your podmin is going to be rough, he’ll simply put a sniffer on their server capturing your password as you login. You can’t be secure if the data is leaving your machine isn’t encrypted so that nobody else than the recipient can decrypt it, and vice versa. Which currently is almost impossible to do for webapps.

Please note that we do already effectively block the friends of friends style social graph analysis. Only your home pod knows all your contacts, and even that doesn’t allow to go beyond that one level. This is what the “you could also like” algorithms are based on in classical social networks.

So the real issue I see here is communication. Lets make clear that Diaspora is not meant as secure communication channel, it’s not meant as the ultimate privacy machine. It’s meant to save your data from exploitation, without limiting you too much in your user experience.

1 Like
3

@Justinthomas has had a nice fork that is able to encrypt private messages from user to user in diaspora in the webbrowser via Javascript. In fact, this works only for direct messages with only one recipient, status-messages are something very different. And yet it is a bit clumpsy for the user, but as a prrof of concept it works absolutely nice.

4

@jonnehass

If your podmin is going to be rough, he’ll simply put a sniffer on his server capturing your password as you login

Yeah, sure. Of course, we have to trust our podmin. But do we have to trust every podmins? That’s really different.

@goob Currently, data are stored in plain text, that means that we have to trust our podmin and every podmins of every friends. The Diaspora* logic is, everyone trusts his podmin (so my friend trusts his podmin and I trust my podmin), and I trust my friend, so everything is okay.

5

@flaburgan the point is that with having your plaintext password he has the same access rights that you have, so he can see everything you can see. So that’s the same situation we have currently, just with a lot more overhead.

6

@jonnehass but my podmin has my password, but not the other podmins. There is a big difference between trusting one node or trusting the whole network. Is this possible to have to trust only your podmin, not the others?

7

When encrypting data when stored, the amount of information a podmin could see wouldn’t change.

Think about until you got it or can prove me wrong.

8

@jonnehass I’ve just noticed I never acknowledged or thanked you for your explanation, which was really useful. Apologies for that oversight.

9

No worries :wink:

10

I am agreeing here with @goob and @flaburgan .

@jonnehass I think people that are moving from facebook and Co to diaspora (like me) are doing so, primarily because of the privacy issues. Especially in these times. I think, to be successful, diaspora HAS to concentrate on the privacy thing, as with the other aspects it’s far from the current feature set of e.g. facebook.

What is in your eyes the argument, that drives people away from facebook towards diaspora?

“Diaspora is about taking your data from cooperation, ensuring its value isn’t exploited without you noticing.”.
And I think, that you cannot ensure that with the current diaspora. If a company wants to crawl some diaspora data they just have to set up a pod, create some pod users, friend with ppl. on other pods and soon they will have collected data which they can sell. Or am I wrong?

But actually, this is the even smaller risk. Even worse, if somebody hacks an existing pod, preferably a big one, and collects all the unencrypted data from there. There are many bad ppl. out there. Storing the data unencryptedly and saying that this is OK for what diaspora is, sounds kind of naive to me (no offence), because such a hack will definitely happen at some point.

Now in times of NSA and PRISM. Ok, they can not read the transported data. But they can hack the pods. So, in my eyes its not the podmin who is the risk, who might have access to the unencrypted date on the pod, but every hacker who intrudes it.

So, to conclude. I would like to hear some real contra arguments, why it wouldn’t be a good thing to incorporate this into diaspora. I don’t think it would be easy to implement in an efficient way, but is that a reason to say no altogether? If performance on the pods is an issue, it might even be possible to make the encrypted storage optional on the pod, but then i as a user would like to be able to select, whether my data is transferred to unencrypted pods.

1 Like
11

It’s hard to impossible to properly implement and that alone should suffice as an argument. Let’s face it, we currently don’t have anybody with enough time and the required skill set to achieve this in any sane way contributing to diaspora. Anything we would do would be half-baked, make us look like amateurs even more and just create a false sense of security. Currently it’s the podmins job to properly secure his system, encrypt his servers hard disks and have the wipe tools ready.

12

I think since this was opened Facebook has added support for PGP keys that can be pasted to the profile and sending PGP encrypted notifications.

That is something I would like to also see with Diaspora.

13

This facebook feature is just in regard to E-Mail. They still have access to everything.

14

This way they could just access public posts. I find the prospect of a company buying a pod more tricky. Also server hosting providers have physical access and usually make backups, which they officially delete… I think, a diaspora client app with in-built encryption for chats would be nice. As a temporary workaround, one could use pidgin with OTR plugin on Diaspora’s Prosody/XMPP integration, I suppose…

15

Hi
May be theres is a resources-saving-privacity-guaranting, good solution based in 5.1 of RFC2440
I whant to write a whitepaper about.
Can I have access to some data?

  • Statistics about max and medium aspects size
  • Statistics about medium an max aspects composition change frecuence.
    Thank you.
16

It is just me but secure messaging isn’t easy to do properly, especially if security is expected to be functional and just a gimmick. Taking that into consideration and also the old idea of not putting all eggs into the same basket I think it is better to use separate dedicated messaging tools for secure communication.

17

I totally agree with you, I chose to use converse.js on my pod and it offers omemo encryption which works well. Of course it’s not as seemless as a signal app for example but once you trust the keys of the user you’re speaking with it works just fine.
I encourage everyone to give it a try.