Join GitHub today
Proposal for improving private toot security #4208
Elaborating on #4205 (comment)
Problem description: When a private toot lands on a non-Mastodon server, that server handles it like a public toot. When does this happen? When a Mastodon user has non-Mastodon followers (GNU social, Friendica) and uses the private toot feature. Mastodon users and users of other fediverse software are not that interspersed, so it doesn't happen often, but it is a risk that has to be reflected in UI warnings, and one which gives a very uncomfortable feeling to users.
Why does it happen? OStatus did not have a concept of privacy when it was designed. The privacy features had to be added by me on top of the protocol. The problem is divided in two things:
So to summarize, the problem is that private toots should've been a breaking-compatibility change, but weren't.
Solution: HTTP signatures (#4146, #4205) is a nice simple way of connecting an OStatus user (and by extension, "instance") to a HTTP request. This is meant for cross-server access-control. It's kind of no big deal, however, we can mandate that a PuSH subscription must be signed that way for private toots to be sent to it. It doesn't even matter which user is picked for the signature, we're only interested in the "domain" part of the user. It's not hard to implement, however it would take deliberate implementation on the part of other software. That way, it would become a compatibility barrier that affects only private toots.
What this doesn't solve:
That can only be solved by end-to-end encryption, which by definition cannot be implemented on the server, so I am powerless (though I can simplify key exchange with some kind of API)
What this also doesn't solve:
This and the main issue of this thread would also be solved by ActivityPub, which provides core syntax for message privacy. However, ActivityPub implementation is taking time.
I'm for this proposal, but I note that encryption would be better to keep the capability of end-to-end security in the protocol.
OStatus allows each accounts to have its own key. That is meaningless for GNU Social and Mastodon, which requires users to trust servers. However, it allows to create another software, or extend those implementations, to ensure end-to-end integrity.
Private toots requires confidentiality as well. Though TLS would be sufficient for Mastodon, we should consider to allow to use encryption using keys of accounts and to have end-to-end confidentiality, especially if we respect the thought of OStatus.
I like akihikodaki's suggestion -- although I was unaware of the account key option. Good to know. ^_^
What I'd almost suggest is splitting 'private' into two types, effectively -- the toots we know (and sort of love) would eventually migrate to ActivityPub, and in the meantime will be "potentially going to servers" and such, all warnings in place, etc.
A toot status ABOVE that in security (or below it in terms of distribution nature, I suppose, depending on one's view of things), with its own different name (which I don't have a great suggestion for at the moment!) could exist, and either
The former would require some infrastructural things that I haven't the foggiest about the feasibility/implementation-ease of, but I think it's possible. The latter would probably require much less, although I suppose the latter may seem a little gray-area in terms of ethics -- it's arguably sending information you KNOW is going to fail on the other end, and no doubt some will consider that intentional noise traffic in some senses -- but I think it'd kind of solve the problem without requiring addition of encryption for true E-to-E.
Either way, it'd leave 'private' messages for people who consider that sufficient privacy (and don't care if GNU/Social can see their messages, and so any of their GS followers can see them properly and such) and give something more approaching 'secure' for those of us who are doing everything to avoid GNU/Social.
(Also, this is a take from someone unfamiliar with the code, obviously -- but hopefully something in here's a useful idea, or a bread crumb leading to one. ^_^)
Actually public keys can be retrieved just by knocking WebFinger and that does not require to follow the account, so that does not work.
To ensure privacy of such statuses, they should be encrypted with public keys of recipients. Recipients can decrypt them with their private keys.
Implementing such features would not be so difficult, but we should be careful since that would be a radical change in the protocol.
EDIT: the protocol would involve XML Encryption or a similar protocol.
Well, there's a reason I don't work in development ^_^
This is why I was suggesting a separate message type for them, one specific to Mastodon that wouldn't play with OStatus at all -- retaining the 'private' message type exists for people who are just looking to propagate to specific users (and their instances), and adding a 'locked' message type or something that's specifically only going to work with Mastodon instances.
My understanding was that the protocol can be added to by Masto in this way but required messaging still has to be allowed for things not being added on to for Masto-specific elements.
(Hopefully that clarifies -- and again, I realize the concept may be wrong, sorry if it's not helpful! ^_^ )