Mastodon delays firm fix for link previews DDoSing sites

Mastodon has pushed back an update that's expected to fully address the issue of link previews sparking accidental distributed denial of service (DDoS) attacks. The problem with link previews hitting sites with bursts of traffic has been observed for over a year now, and although version 4.3.0 was slated to have a formal fix …

[Len]

A side effect of success

This issue has always existed of course, but it wasn't until Mastodon exploded in popularity that it became a frequent problem. After Elon Musk started to take an axe to Twitter the Mastodon network gained more users in some months than it had gained in the six years prior.

What happens is essentially the 'Slashdot effect', or similar to sending out a bulk email with links to your website. You may have hundreds of thousands of users with their own clients behind their unique IPs that all want a bit of data from your server, it's truly 'Distributed'.

I make sure that all the content that Mastodon servers would want from my sites to generate a link preview is static and that mostly seems to prevent the issue, for me at least. But, if you have a site that needs to fetch OpenGraph snippets from a database you need to take optimisation pretty seriously, or use a CDN proxy type services to do some of the caching for you.

[Anonymous Coward]

Re: A side effect of success

A side effect of success has been the Reddit hug of death for years after Slashdot traffic fell off.

Glad the Mastodon team are trying to reduce the load, but as you point out this isn't new. It would be worse if it was random individual traffic.

Remember, it's easier to fail at scale...

[FF22]

Re: A side effect of success

"This issue has always existed of course [..] What happens is essentially the 'Slashdot effect'"

No. This is a far more severe issue.

The problem is twofold. For one, in this case it's not only those users who actually click through to the referred site, that are generating network traffic, but everyone else who gets the shared content shown in the form of a thumbnail. And that's generally a 50-100-fold increase in traffic to let's say having an excerpt of an article posted to Slashdot, Facebook, or whatever - as most people who get the preview shown usually don't click through to the source; but with Mastodon they (their client) will still all download the full page.

The other - more severe issue - is that most of that extra traffic does not yield any income to the operators/publishers of the target site. Under normal circumstances, when someone clicks through the original site, they'll not only generate network traffic, take up server resources, etc., but also allow - by actually loading the page in their browsers - the operators/publishers to cover the costs of said network traffic, server resources, etc. for ex. through the showing of ads. However, when it's only a link preview that's shown to the user, there's no way for the operators/publishers to recoup the costs of serving the data for the preview.

So, even if their server and network connection can actually handle the excess traffic, they'll now only be able to recoup like 1/50th-1/100th of the costs than under normal circumstances. And this generally breaks to business model the free web is built on. All that because Mastodon developers are lazy to implement some kind of preview caching or preview distribution alongside the messages themselves.

Btw the lack of cached previews is also disadvantegous to the privacy of Mastodon users, because it makes it easy for bad actors to track who's been reading a particular feed or following a particular source - just because every single user who has the referred content link appearing in their feeds will have their IPs revealed as their Mastodon client is accessing the target site in order to retrieve the content that's needed to generate the link preview. For every single one of them.

[David Taylor 1]

Re: A side effect of success

No, it's not every client, it's every server that federates the post.

This also avoids the privacy issue you invented.

Perhaps do some fact checking first...

[FF22]

Re: A side effect of success

A federated server is also a client. And the privacy issue is still there.

Maybe next time educate yourself about the basics of network architectures before commenting

[Brewster's Angle Grinder]

I don't use Mastodon, but...

What you say is sensible, until you go "All that because Mastodon developers are lazy to implement some kind of preview caching or preview distribution alongside the messages themselves."

If you can understand the rest, can you not understand how difficult that might be? As they note, 1½ devs have to get the ActivityPub protocol changed (which is a W3C standard), and those changes will have to include crypto signatures to ensure previews don't become a vector for spam.

Or, if you prefer, we could engage in retaliatory name calling at the devs whose web sites can't handle this.

[FF22]

Re: I don't use Mastodon, but...

The preview does not differ in any way from the link in trustability. If the link can be trusted, then the preview can be also. If the link can not be trusted, then the preview still does not pose an additional risk and the problem lies with the system that allows sharing and propagation of an untrusted or possible harmful link.

It's just lazyness, and pushing the cost of that onto third parties, as already explained.

[TheRON]

There are other clients besides Mastodon

Some of us on the fedi are trying to convince users to try other clients such as Hubzilla / Streams which have alternative native protocols. ActivityPub is not fully developed as there is little demand - which did not stop the Zot folks to code and fully evolve Zot. As more protocols are put to use these sorts of issues going to be less of a problem.

[omz13]

Re: There are other clients besides Mastodon

The problem is that, for better or worse, Fediverse is ActivityPub, and ActivityPub is Mastodon. Now, you could argue that the Fediverse is not one protocol, or one implementation of a protocol, but the elephant in the room that is Mastodon has done just that. If you remember your history, VHS was not as good as Betamax, but which one of those “won”? You can apply the same thinking to ActivityPub/Mastodon and Zot/Hubzilla. The problem is compounded because ActivityPub/Mastodon is currently getting all the attention and, more importantly funding.

[Tron]

The architecture is flawed,

Distributed social media should see such data move in encrypted packets from user to user [via e-mail or other protocols], without needing to pull data from a website.

[Throatwarbler Mangrove]

Re: The architecture is flawed,

Why?

[Throatwarbler Mangrove]

Re: The architecture is flawed,

Ah, so when someone asks you why you've made a blanket statement about distributed architecture with nothing to support it, you downvote rather than explain. So, to summarize, you are full of shit.

[Anonymous Coward]

Re: The architecture is flawed,

I don't think you understand what this issue is about. This isn't about Alice making a post and Bob receiving it in order to read it. As it stands that would require just two servers (Alice's Mastodon server to host the post that her ActivityPub client has posted, and Bob's Mastodon server that pulls the post from Alice's Mastodon server so it can send it to Bob's ActivityPub client) and there's no reason why all that information would not be transmitted encrypted over the wire without ever seeing a website.

This particular problem is about Alice's friend Charlie having a blog hosted on a website. Alice liked one of Charlie's latest blog posts and decides to create a post with a link to it. Alice's Mastodon server grabs some metadata about the blog post such as an OpenGraph snippet and the image for a link preview. Bob follows Alice's Mastodon account so his Mastodon server grabs that same metadata from the original website for a link preview to show to Bob. If Alice has 100K followers on Mastodon and Bob has 50K then all their followers (who may reside on thousands of different servers) all require to grab that preview. This means that if a Mastodon post with a link to a website goes viral this could cause a flood of OpenGraph grabs. As the amount of data is pretty small many website setups should be able to handle this if the information is static, or properly cached. If it needs to be grabbed from a database on every single occasion that can get out of hand.

[Claptrap314]

This is a solved problem

In fact, it is solved for all versions of the problem.

I learned the solution for a set of them at Google in 2015. That solution generalizes quite well.

[Throatwarbler Mangrove]

Re: This is a solved problem

Great. What's the solution, Brainiac?

[The Dogs Meevonks]

It's not perfect - But look at the alternatives

Even with it's shortcomings, Mastodon is still a thousand times better than ALL of the other social media sites combined.

I get far more engagement on there than I ever did anywhere else except for the very much missed G+ of 2011-2016 before they started gutting it and stripping out the best parts to use a stand alone products.

I left faecesbook in 2011 or 2012, twatter... well, I left that for years at a time, dipped my toe in for a few days or a week and went 'oh yeah, this place is fucking toxic & am I only here to occasionally reconnect with an old flame and catch up. I never signed up for any of the others at all. But I do still have a whatsapp acct for dealing with family... everything else is done via signal/telegram/mastodon.

If you're not on any of those and complain that I'm not on your choices as justification for not keeping in touch... you'll get a swift response that says either 'but you're not on (insert app here)' as a direct response to their bullshit or 'I can't be bothered making an effort with people who refuse to make any'

I'm much rather stay in touch with people who appreciate me... everyone else is a 'former' friend or just an old acquaintance.