I want to try diaspora*, but I have some questions about how it works

Support
1

Privacy

  • I plan to run my own pod. If someone from another pod follows me and sees one of my posts, does that post get stored on their pod? If so, could the admin of that pod read my post?

  • When someone gets a post from me, how is the data protected in transmission?

  • How are public posts fetched? If there are 100,000 pods with a million users total, how does diaspora* find any posts? How is that indexed?

  • How does re-sharing work? Can someone re-share something publicly I shared privately with them? Is there any way to disable re-sharing?

I realize that on some level preventing re-sharing is impossible, someone can always take a screenshot or copy / paste the information. Possibly even capturing the raw data to get my key and prove I sent it.

I’m thinking of something more like a locked door, which is just a request for privacy that most people will respect. If I share about a recently deceased family member, I might disable re-sharing to indicate that I don’t yet want this to spread beyond who I shared with. Of course someone could be mean and circumvent that, but the average person won’t go out of their way to break that social contract.

Freedom

  • Is there any way for someone (including the diaspora* team) to moderate my posts if I run my own pod?

For example, if I abuse the NSFW system and consistently post unflagged gore and the like, can anyone take away my ability of post?

Or if I communicate illegally, (for example, I live in China and criticize the CCP) will anyone from the diaspora* team be able to cooperate with the government in my prosecution? (Obviously anyone I shared a post with could share and the government could take my server, that’s not what I’m asking about.)

These are extreme examples, but it gets the point across, if those are impossible then I have confidence that liberty is respected.

Admin

  • If I want to run a pod for my technically disinclined friends and family, can I have a closed registration where access is restricted only to people I approve?

  • Can I handle password resets without an email service?

I’m still figuring out being a server admin and I don’t have an email solution. All I have is protonmail, which the terms of service forbid using as an automated mailing system. I’m happy to manually reset passwords as long as that is possible, I don’t intend to administrate more than a few dozen users.

If diaspora* meets my criteria on privacy / liberty, and I can administrate a server for my family, I will likely begin to set up a pod.

Thank you so much for your time.

2

Hi, and welcome. Due to the high number of questions, I’ll be very brief. Please ask follow-ups if you have any. Generally speaking, please see our FAQ for Pod Maintainers, and our FAQ for Users.

Yes.

Yes.

For private posts, contents are signed and encrypted with asymmetric cipher’s using the recipient’s key, see the federation docs. Public posts are signed with your key, but not encrypted.

They are not. diaspora* does not use any kind of central and/or global relay to subscribe to. You only receive contents from pods that know about your existence, see this podmin FAQ as well as this podmin FAQ.

UX-wise, resharing works by clicking the reshare buttons on public posts. Technically, we federate a reference to the original post, which allows receiving pods to fetch the post from its source if necessary.

No, but also yes. diaspora* does not allow resharing of private posts in the UI, and force-resharing a private post by manually crafting the payload will result in nothing usable, since private posts cannot be fetched.

However, as you correctly identified, diaspora* is not a guarantee and diaspora* can’t solve social and technical constraints. Other networks, like Friendica for example, don’t actually reshare, and just “full-quote” the text. While they do not allow resharing private stuff by default, there is no way we can limit this. In general, there is no actual way we can limit distribution if someone really wants to leak your private stuff, just like we can’t prevent people from taking a screenshot and posting that screenshot.

diaspora* allows you to choose who you want to trust, but trusting people is a social construct, not a technical one, and there is no way to technically enforce confidentiality.

You cannot disable re-sharing of public posts. When you post something public, you made something public.

If you share something about a deceased family member, you would pick your aspects (diaspora* terminology for “contact group”) manually, i.e. you would manually pick the people who would receive your post. That is, by diaspora*s definition, a private post, and can’t be reshared. The only posts that ever can be reshared are the ones you mark as “public”, and public means public.

There is not. Other podmins can blocklist your pod from federating inbound, and I will personally sue you based on trademark laws if you use the project’s name for malicious intent. However, the code is free and open source software, and there is nothing stopping podmins from using that source. Note, however, that people who consciously and repeatedly violate diaspora*s community guidelines are not welcome in our project’s community, which includes this Discourse, but also discussions on GitHub or on IRC.

There is no exposure of any private data besides the data your pod deliberately shares (like federated posts, and by that measure, the pods IP and whatnot). As far as we are aware, there are no security issues that could be used to “discover” private details, and there also is no backdoor.

However, we can obviously assist in cases where we see it necessary, for example by providing a list of known-to-us pods with certain types of content (see, for example, this and this blog post from 2014), and we’ll also redirect any and all lawsuits misdirected at us when they should instead target an individual pod.

You can disable public registrations, which would allow you to manually send invite links to people you want to have on your pod. There currently is no mechanism to approve new registrations, but a feature request exists.

Not within the UI. You can, however, use the Rails console for that, see this post for example.

3

Thanks for the responses! Much appreciated. :slightly_smiling_face:

To clarify, is this true of both public and private posts or just public posts? I have several follow-up questions if it’s both, but I should clarify before getting into that.

I think everything else is satisfactorily answered! Thanks again!

4

Yes. Contents are encrypted on transport, but they aren’t stored encrypted because that doesn’t really make sense.

5

Alright, good to know, thank you!

That is actually a point of concern for me. That means that if I want to privately share something with someone, I must trust not just them, but also their podmin. Personally, I don’t feel comfortable sharing important life details knowing that a podmin can freely snoop through them.

Also, that seems to allow podmins to exercise authoritarian control over their users. For example (not that I want to do this) if I see that one of my friends is engaging in political speech disagreeable to me with someone from another pod, I could just ban that pod. On a small scale, that’s probably not a huge problem, but if pods grow very large, that’s a lot of power for the podmin to wield.

Personally, I would feel better if that capability didn’t exist. I know some trust is required to have a relationship in the first place, but I would prefer to keep that circle of trust as small as possible. If I was willing to trust unknown people to not snoop through my data, then I would probably just use Facebook.

I’m willing to be convinced otherwise if you find it worth your time, but I don’t expect you to. I’m just some rando, you don’t owe me an explanation / debate.

6

Storing things encrypted on the server is only useful if you can separate data storage from data retrieval/decryption physically and logically.

If the party who runs a theoretical zero-knowledge storage is the same party that provides you with the client to retrieve and decrypt the data, the whole encryption is worthless since a rouge podmin could simply serve you a client that sends them a copy of your decryption key. Since diaspora* is first and foremost a browser-based application, your pod is pretty much always the one also serving you the UI. A theoretical exception exists where a client may exist that only consumes the API, but that’s not valid at the moment because the API isn’t even yet in the stable release.

Implementing server-side encryption would allow us to use a lot of fancy marketing buzzwords and create a lot of perceived security, but there wouldn’t be any actual gain, so we’d rather not.

Even ignoring these technical facts, having a zero-knowledge server makes some of the current features impossible. The server absolutely needs to know a post’s contents to generate embeds, send out mention notifications, make tag-filtered streams work, queue content-fetches for unknown contents linked via a diaspora://-link, and so much more.

And that’s still talking about technical things, I won’t even go into the nightmare that is UX, with forcing users to manually keep track of their decryption key, or telling them that their entire posting history and all content ever received is gone because they accidentally dropped their phone.

Storing contents encrypted is a request as old as the project itself, but it’s unlikely to ever happen. See also the following reply, and that thread as a whole:

Don’t worry, we’re used to this. :wink:

7

Those are actually really strong points. The concept of using pods rather than each user hosting their own instance is more or less a convenience made specifically for less technically inclined users. It does seem kind of irresponsible to ask that crowd to keep track of their keys and they lose their history if they lose the key. If everyone was in “one-person-pods”, then this would be a non-issue, but that’s not realistic.

I may have to scale back my expectations if I want the majority of my friends and family to be able to see my updates.

And I suppose my Facebook characterization wasn’t really fair, if a podmin begins behaving badly, the federated system allows people to just leave for a different pod. That’s not really true of Facebook, at least not to the same degree.

If I really need to talk one-on-one with someone in a secure way, I have Signal, or things like it. For general life updates that I expect a fair number of people to know about, I may have to accept some risk, just like there’s risk in real life that someone could be physically spying on me.

I think I have heard enough to give diaspora* an honest try. I am also a software developer, so once I learn the system, if it seems to work for my family and friends, I would probably be interested in helping improve the network.

Thank you! You’ve been very kind to me!

3 Likes
8

I like that phrasing. Indeed, there is no “perfect” system, and diaspora* tries to offer significant improvement over centralized systems with no control whatsoever, but we also try to be more user-friendly than some of the projects with a heavy focus on e2e encryption and so on. Some of the “amazing” technical concepts are simply too much for the average users, so finding a good-enough compromise is what we try to do; maybe successfully, maybe not. :slight_smile:

Glad I could help. Let us know if you have more questions, we’re usually really happy to help out!

1 Like
9

There’s also a balance to be struck by having a podmin who doesn’t know you host your (possibly illegal, defamatory, or in other ways difficult) content on their pod. As a podmin, I need to limit my personal liability and exposure to the behavior of my users, and if a set of users doesn’t trust me to not snoop their data (Dennis’ perfectly valid technical constraints aside), then they shouldn’t rely on me to host and maintain their data. Transparency is the key here, I think.

As a side note, I want to commend everyone for creating a great thread with lots of high-value content. Well done!