Mastodon's federation introduces UX challenges.
One that worries me a lot is about message forgery. Anyone can forge a twoot, even cross-server.
Whereas Twitter Inc might be trustworthy enough to not forge transcripts. Anyone can run a Mastodon server and might want to abuse it to influence people (see Russian troll campaigns).
Should Mastodon "home servers" cryptographically sign updates? Should there be end-to-end signatures? Anyone has thoughts on this?
@fj Isn't it already?
Offending instances can be banned entirely from federating, it's not just for certain users :)
@fj Totally. Some sort of signing makes sense, but as far as I can tell, there isn't yet a GNU Social implementation that incorporates signing or a distributed ledger.
@fj how does the federation work on mastodon? If a server can only "forward" messages from his own users I don't see a big problem as long as the message origin is clear.
@fj agree 100% if the ecosystem is going to be federated then cryptographic signing is a requirement
so you're claiming that I could spoof a post as, for example, you, @fj ?
@fj Finally a security complaint that isn't just "someone could get my username on another instance".
@fj would like to see some sort of signing for messages. Any encryption is better than none IMHO
I can see this platform being used by some state level players attempting to control.
@trwnh Blocking entire federated instances that are up to no good is definitely a plus. Is this already implemented? and who would do the blocking?
@fj good points. It will only get better from here on out. Lots of new servers popped up since last night.
Messages should definitely be signed but then you also need a native client.
@fj it would be good to make the cross instance accounts more visible. the instance tends to get cut off on the timeline. maybe an icon should be added beside cross instance messages? or allow instances to set a favicon for their instance which is shown on all of the timelines?
@martijn_grooten Sure but it will still appear as "firstname.lastname@example.org" on people's clients. Domains just don't show up when you're on the same server as the other person, then they are implicitly assumed.
@martijn_grooten next step for Mastodon is to put all the usernames in a distributed ledger run by all the Mastodon servers to have a unique blockchain of usernames. #BlockchainAllTheThings #WhenAllYouHaveIsABlockchainEverythingLooksLikeANail
@fj Yeah, I don't think mentions are going to be very confusing. But imposter accounts? But maybe Mastodon isn't meant to be widely used; for a geeks-only social network, it's probably fine, and the decentralisation is a neat idea.
@martijn_grooten @fj backgrounds from users you follow should be slightly different colors. backgrounds of users with the same name as a follow but are not that account should have a different different color too. The 'web of trust' is already handled by DNS, HTTPS, and the ability of Mastodon instance owners to unfederate with specific servers. It may come where the biggest servers are whitelist-only with an application process. or maybe 'local/trusted/federated'
@fj @martijn_grooten a plug-in for 'verified' could be made that individual mastodon servers could opt-in and add support for on their pages. a problem persists in mastodon servers that would give them out to everyone. but it would still be a baseline. 'that accounts not even verified, and practically everyone is verified on ___________'
@fj Some kind of Web of Trust implementation might help, in the sense that contacts can rate one another. You could also verify someone based on how many contacts they have, and what threshold of daily interaction they keep with said contacts.
@fj That's a very important thing to think about. There has to be a balance between having it be a usable social network, yet viable as a P2P protocol
@fj Yeah I don't use this for any sort of srs business. true federation needs key infrastructure. that's one thing matrix gets right on
@fj I kinda think end-to-end signing of toots is the way to go. Then it wouldn't even have to rely on the clients.
@fj how would the forgery work?
@fj Doesn't do harm to require content signing as it provides source verification. Along with certificate pinning you can spot impostors. It also enables adding per certificate trust levels for server-to-server and end user identification or source via visual representation of the key's fingerprint.
@fj XMPP solved these problems already and has been used at large enough scale to be confident that it works so we should transition to XMPP instead of trying to fix ostatus, IMHO
@fj Definitely need signatures at server level, even if not at individual level.
@fj you could use pgp-like signing on messages and then have other people trust your key (again, like pgp) thereby building a web of trust.
Additionally, if you see a toot which is signed by a key that more than 50% of people you trust also trust, a checkmark (like twitters verified icon) could be displayed
@fj sounds like matrix.org
@fj What we need is a way to to shun servers at the individual level, and then we can start to say, "Oh you don't vet IDs? Well I won't listen to you."
@fj anyone can also forge emails, doesn't seem to be too much of an issue tho. Perhaps we need to digitally sign important toots
@fj I view it as IRC, not as news.
@fj Verifying messages is important / critical in a federated network. In ActivityPub it's required to technically conform to the standard, though how you do it is somewhat looser; eg if you "share" a message, and that message is embedded and comes from a different origin, the most minimalist approach is to check the source and make sure it matches.
But signatures are better... [... contd ...]
@fj The "right" way to do it is definitely to sign messages as you pass them along the network. We include a section for this using Linked Data Signatures and HTTP Signatures https://www.w3.org/TR/activitypub/#authorization-lds
Unfortunately, it's non-normative. The specs need more use and "proof in implementation" before they can become the de-facto way. It would have been way better to make it the definitive way to do it (but at least a method is presented)
@fj If Mastodon does implement ActivityPub, I'd love to work with Mastodon to make sure that we get implement this cooperatively / interoperably. I know Jason Robinson is also interested and hopes to do so this summer.
@mikegerwitz I'm not sure about PGP's web of trust stuff specifically, but one sekret aspect of the Verifiable Claims work is it might allow a federated network to *turn into* a web of trust, without the usual WoT user experience issues.
(I haven't thought about how to integrate with existing PGP WoT tho)
I see you're also talking about the concern of "delegating" key trust to a server... that's a whole topic itself...
Btw @mikegerwitz you might appreciate this article, "An even more distributed ActivityPub" http://dustycloud.org/blog/an-even-more-distributed-activitypub/
@mikegerwitz One more thing along "even more distributed": it *should* be possible to use ActivityPub on a more peer to peer / distributed system than HTTP. Luckily URIs can have different schemas... so you could handle a different network layer there. The one thing you'll still need is HTTP GET/POST to comply w/ AP.
The fastest route to thinking about what that might look like is to think about using Tor .onion addresses; but there are better examples possible.
@mikegerwitz It's out of scope for current work of the SocialWG, but maybe something that will be explored in the follow-up Community Group. Focusing on making the web we have be better federated is the current goal obviously... but we can do even better, with surprisingly few changes and I believe backwards compatible changes. (But maybe not forwards compatible, as in nodes that don't understand the p2p uri schemas might not know what's going on).
@fj I'm not an expert on the OStatus protocol used by Mastodon, but if I understand correctly, messages are signed and exchanged through the Salmon protocol. So I don't think it's as easy to forge a toot as it is to forge, say, an email on a domain that doesn't use SPF
@fj whoops, the previous replies weren't showing up in my client, sorry for the redundant reply!
@fj maybe some signature system based on keybase would allow to prove the identity of the toot
@fj e2e is mandatory at least for dm. Signature should also be implemented in order to be able to validate both accounts and contents.
Not easy, but if we want to be able to trust contents and members, it must be there, and in the easiest possible way so that everybody can use it without hassle nor pain.
@fj we have the same problem with email... PGP was the answer yet nobody use it. Today most email server use a lot of tricks to guess if the email is real... but still hacky.
Perhaps it's good than mastodon is not that safe, it will keep corporation out of the game ;).
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!