There’s some problem with a federated previews: tricking one instance into generating the wrong preview would spread to every instance. It’s been exploited for malware and scam campaigns in message apps.
Here’s a related, interesting example for BlueSky, on generating disguised links and preview cards (with content the url doesn’t actually contain) for anyone curious: https://github.com/qwell/bsky-exploits
And also have my instance intercept it to provide Google’s embed preview image, and it federates that with other instances.
Now, for everyone it would look like a Google link, but you get Microsoft Google instead.
I could also actually post a genuine Google link but make the preview go somewhere else completely, so people may see the link goes where they expect even when putting the mouse over it, but then they end up clicking the preview for whatever reason. Bam, wrong site. Could also be a YouTube link and embed but the embed shows a completely different preview image, you click on it and get some gore or porn instead. Fake headlines, whatever way you can think of to abuse this, using the cyrillic alphabet, whatever.
People trust those previews in a way, so if you post a shortened link but it previews like a news article you want to go to, you might click the image or headline but end up on a phony clone of the site loaded with malware. Currently, if you trust your instance you can actually trust the embed because it’s generated by your instance.
On iMessage, it used that the sender would send the embed metadata, so it was used for a zero click exploit by sending an embed of a real site but with an attachment that exploited the codec it would be rendered with.
So the preview should be federated as well?
How many requests are we actually talking about here, though? Is that better or worse than everyone clicking the link?
There’s some problem with a federated previews: tricking one instance into generating the wrong preview would spread to every instance. It’s been exploited for malware and scam campaigns in message apps.
Here’s a related, interesting example for BlueSky, on generating disguised links and preview cards (with content the url doesn’t actually contain) for anyone curious: https://github.com/qwell/bsky-exploits
What is the threat model here?
Masquerading a normal looking link for another one, usually phishing, malware, clones loaded with ads.
Like, lets say I post something like
And also have my instance intercept it to provide Google’s embed preview image, and it federates that with other instances.
Now, for everyone it would look like a Google link, but you get Microsoft Google instead.
I could also actually post a genuine Google link but make the preview go somewhere else completely, so people may see the link goes where they expect even when putting the mouse over it, but then they end up clicking the preview for whatever reason. Bam, wrong site. Could also be a YouTube link and embed but the embed shows a completely different preview image, you click on it and get some gore or porn instead. Fake headlines, whatever way you can think of to abuse this, using the cyrillic alphabet, whatever.
People trust those previews in a way, so if you post a shortened link but it previews like a news article you want to go to, you might click the image or headline but end up on a phony clone of the site loaded with malware. Currently, if you trust your instance you can actually trust the embed because it’s generated by your instance.
On iMessage, it used that the sender would send the embed metadata, so it was used for a zero click exploit by sending an embed of a real site but with an attachment that exploited the codec it would be rendered with.
Couldn’t a malicious ActivityPub server do similar things now?
2 requests per instance - one for the HTML of the page and another for a preview image.