I was recommended to share this article I wrote a few days ago on here, too; so here we are!
The TL;DR is “link embed fetching communes” as a partial “fix” to the issue (pretty buzzwordy, sorry for that)
I was recommended to share this article I wrote a few days ago on here, too; so here we are!
The TL;DR is “link embed fetching communes” as a partial “fix” to the issue (pretty buzzwordy, sorry for that)
Without some kind of signature scheme, this can easily be abused, though. The first server to fetch the embed can put just about anything in there when it pushes that embed to other servers.
The first server should be the one it was posted to. Then federate the embed just like the post itself.
If a server is malicious, it doesn’t matter if that malice is transmitted in the post or in the embed, it should be defederated just the same.
Sharing Federated content in general works like that. However, the originating server will still receive an onslaught of HTTPS requests of remote servers fetching the signing key used to sign the federated message.
“Just defederate” is not a real solution. I’ve observed malicious behaviour on all major Lemmy, Kbin, and Mastodon services, and even more on smaller services like personal Mastodon servers.
In this case, generating fake excerpts is not something a user on a server controlled by someone else can do; they have to operate a malicious server themselves. Defederation is a good solution to malicious servers.
Certainly someone very determined could spin up a bunch of malicious servers and put out a bunch of posts containing fake excerpts, but they’d need followers to get any reach on the microblog side of the fediverse. They could spam Lemmy communities, but users would notice and downvote/report the posts.
So I think “just defederate” probably is an adequate solution here, at least as things currently sit. Were the fediverse to grow by an order of magnitude, I think it would need a reputation system to add a bit of friction to a brand new server or user getting a lot of reach quickly.
ActivityPub doesn’t require followers, it’s a push-based protocol. You can tag a user, and your post gets embedded in the remote timeline. The lack of the ability to cut down on notifications is actually one of the problems many of the more popular fediverse accounts often talk about.
One could implement a sort of “I trust your supposed representation but only if the recipients follow you” approach, but then you’ll need to explain to users why sometimes link previews work and why sometimes they don’t.
This issue could still be prevented entirely in a whitelisted federation model where hacked servers get defederated immediately, but I don’t think that’s a particularly popular model within ActivityPub circles.
There are a few reputation systems out there, but they have the exact same problem email reputation services have: your small server will never be able to exchange messages with the four or five largest servers because there’s no way for you to build up a reputation in the first place, and a 30 minute hack can make your domain completely unusable.
Not all servers are equal. I would trust a post from lemmy.world or lemmy.ml to have valid metadata, for example. It’d be great if admins had some way to specify trusted instances (with the biggest 6 instances as initial defaults).
There would be other uses for the trusted instances concept. Automatic sharing of moderation actions, block lists, community lists, etc
That kind of centralisation is exactly what the Fediverse was built to prevent. What’s the point of decentralising if you’re going keep a whitelist of servers and break link previews for all other users? I would certainly keep that feature disabled.
Link previews for content from untrusted instances could still be generated just as they are now.
The centralisation that has happened is a separate issue.