Mastodon: Making federation safer (respecting public/friends/private posts)

[nathanvda]

Just a little brainstorming, please excuse me if this is off the mark, or not the space. This is inspired by a tweetstorm where someone mentioned possible dangers of federation.

The big issue being:

• we are on a well moderated mastodon server M1
• a seemingly benign, well maintained mastodon server M2 connects and our admin sees no harm
• someone from M2 follows my account.

Now it follows that:

• all my toots are federated to M2

Suppose this admin is not benign, they now actually have access to all my toots, even my private/for friends only ones, yes? They are in the database. This might seem far-fetched, but this is an actual loophole, and while an admin can blacklist a server _after the fact_, the data is already shared and readable.

• for public toots there is no problem, it does not matter where you can read those, anybody can read those
• but I would even want my private toots to not be readable to anybody unless specifically given access

So I am thinking of a sort of HTTPS/SSL protocol, where an entire stream is copied, but the private toots are encrypted and anyone requesting access, to read them, has to first "prove" they can, e.g. do a SSL-style handshake and get the public key to read the toots.

While this is not fool-proof, at least it makes sure that accidental or premature federation does not copy or "release" private toots into the wild to a possibly malicious mastodon server, and secondly private toots are always encrypted in the database and could only be decrypted after a valid approvement (the reader has to be follower with the correct access rights).

So in short:

• every user has a key-pair
• private toots are always encrypted in the database
• before getting access to a private tooth, a reader has to prove they have access (handshake)
• toots are only decrpyted in the client and never stored on the server

Another option is to always fetch private toots from the source, and never federate those? It will be considerably slower, but also considerably safer.

This is purely theoretical brainstorming, surely it can be improved in many ways, and maybe I am introducing a lot of issues. Also I have not investigated mastodon into detail so I have no idea how things are implemented at the time.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[Gargron]

First of all, if your account is locked, others have to send a follow request first, and you have to authorize, before they are officially "following" you.

Secondly, M2 in your example would only start receiving future toots from you after the follow was authorized.

[yiskah]

Don't private posts not federate anyway? Admin of M2 would not receive anything but public and unlisted posts.

[wxcafe]

@nathanvda do these replies answer your question? Please close the issue if they do.

[nathanvda]

What @yiskah said is interesting, but it sounded like a question to me, so are private posts federated or not? And if private posts are never federated, is the client UI responsible for retrieving those? I did not immediately find this reflected in the UI code, it only seems to retrieve a single timeline (from the local server, so the toots from remote accounts are supposed to be on the server?). Or can a follower only see private toots when they visit the account of someone they follow (which will be retrieved from their local server). This would be ultimately safe.

But then I checked the code, and afaik every status post is distributed to all followers (DistributionWorker is called unconditionally for every status, and FanOutOnWriteService just delivers to all (mentioned) followers, calls FeedInsertionWorker, but I never see a check on visibility) (superficial look, but the reactions did not give me much to go on).

Secondly, @Gargron: when taking the impersonation problem into account, when I am being followed by someone who pretends to be someone I know and trust (from another social network for instance), I could easily follow them without being aware it is the wrong person. And then my (future) toots would be visible/federated to the other server. Where a malicious admin has complete access to them. Paranoid much? On twitter there are tons of impersonated accounts just thriving to discredit people/organisations, why not create one to lure people?

Mastodon seems really interesting, as a platform, adding private/public toots, with the stricter moderation by admins (but that depends on the instance/admin of course), but what I am missing now, because of the federation is the inherent safety of the federation. This could be caused by limitations in the protocol used, but frankly the answers I got here are either unclear, do not explain anything in detail, and so I get the impression they are condenscending (maybe not intentional, and I understand this is a very busy time for your team, and it is easier to just not think about the _difficult_ parts?).

Obviously, by closing https://github.com/tootsuite/mastodon/issues/913 and the lack of (detailed) response here (aka the unwillingness to either think along or explain, but changing the documentation anyway), it seems to me this not considered a problem. At this moment, my personal takeaway is if I (people) want to use it, and be completely safe, I (they) should only use public toots.

Addendum: just saw commit https://github.com/tootsuite/mastodon/commit/7d354cc8c5eceb1289259f23ecac4d85cb6c1f74 clarifying that private toots _are_ federated and remote servers should not be trusted (by @yiskah 8 days ago, so not sure why he replied that private toots are not federated? :confused: ).

[wxcafe]

Private posts are not federated (yet) except if you specifically tag someone from a remote instance in them.

It is my opinion that implementing a PKI is completely out of the scope of this project, and that it would be extremely complicated (take into account that users will use multiple clients on multiple platforms, maybe multiple accounts, and they should never have to interact with the encryption thing).

When taking the impersonation problem into account, when I am being followed by someone who pretends to be someone I know and trust (from another social network for instance), I could easily follow them without being aware it is the wrong person. And then my (future) toots would be visible/federated to the other server. Where a malicious admin has complete access to them.

Solving phishing is (still imo) also out of the scope of this project. Also, you don't need a malicious admin to see your private toots if you accept a malicious follower: that malicious follower can already see them

Obviously, by closing #913 and the lack of (detailed) response here (aka the unwillingness to either think along or explain, but changing the documentation anyway), it seems to me this not considered a problem. At this moment, my personal takeaway is if I (people) want to use it, and be completely safe, I (they) should only use public toots.

Once again: solving phishing is out of the scope of this project. This is not a problem that's solvable with a decentralised platform except by, once again, implementing a complicated PKI that relies on the users.

[Shnoulle]

Once again: solving phishing is out of the scope of this project. This is not a problem that's solvable with a decentralised platform except by, once again, implementing a complicated PKI that relies on the users.

:+1:

Crypt you toot with PGP ;)

[Gargron]

In practical terms the privacy parts will be fleshed out more in the ActivityPub protocol, therefore this is a duplicate of #1557