hotlinked images for bookmark cards are a bad practice with numerous issues

[thestinger]

Ghost is currently hotlinking images used for bookmark cards: favicons, web manifest icons, Apple touch icons, Open Graph icons, etc. These images break if the site changes the location of the images, which shouldn't break anything as long as they update the references to them. It's also broken by Cross-Origin-Resource-Policy: same-origin.

Beyond the issues with it breaking, it's also a privacy issue since the user's web browser is loading all these images and passing a referrer header unless the blog has disabled it with Referrer-Policy. Each one of these is essentially adding tracking pixels to the page.

This is also simply a bad practice overall. Websites don't link having their images hotlinked and it's not how Open Graph is intended to be used. You're meant to fetch the image that's currently referenced to cache it. The site should be able to change the path of the image. A site might replace / update an image and they usually won't have a redirect from the old location to the new one since it's only meant to be used as currently referenced in the HTML.

I'm writing this not as a user of your software but rather someone having their images hotlinked. I noticed Open Graph images were being used via legacy paths through redirects set up for them and investigated why it was happening. I think for now we'll reluctantly set Cross-Origin-Resource-Policy: cross-origin for the images that are being used to keep it working but this should really be overhauled.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thestinger]

Still an issue.

[github-actions]

Our bot has automatically marked this issue as stale because there has not been any activity here in some time.

The issue will be closed soon if there are no further updates, however we ask that you do not post comments to keep the issue open if you are not actively working on a PR.

We keep the issue list minimal so we can keep focus on the most pressing issues. Closed issues can always be reopened if a new contributor is found. Thank you for understanding 🙂

[Wonderfall]

Still an issue.

[thestinger]

Yeah, but bug reports don't really seem wanted.

[hajjarjoseph]

2023 and still a big issue for us as well!

[michaelnordmeyer]

Still an issue.

It also leaks analytics to the linked sites, because with each request of the hotlinking page a request is being made to the linked site and registered in their server logs.

Thankfully Ghost uses by default a ref URL parameter on outgoing links, which is also a bad practice IMHO, but at least it's easy to redirect all requests coming from a Ghost-powered site to the very same site (nginx: if ($arg_ref) { return 302 https://$arg_ref/; }).

Probably neither the analytics leaks nor the redirecting is something @ErisDS wants for their customers.

If people want to mitigate the problem for at least the favicon, they can use a data URL to embed the icon in the page. A base64-encoded png would be <link rel="icon" type="image/png" href="data:image/png;base64,ICON">, where ICON is the base64 value. On Linux, base64 -w0 icon.png will create the value in the terminal for a file called icon.png, on macOS and *BSD it is base64 -i icon.png. Or use a free online service.

This base64 embedding works in this case, because Ghost's bookmark cards cannot parse data URLs. But it doesn't work retroactively, because the icon has already been linked.

[thestinger]

Closing all open issues if no one is actively working on them is a strange approach. They should close the ones they don't plan to implement, but closing them with no one even taking a look at it is strange.

[michaelnordmeyer]

Apparently the analytics leakage spreads to third-party newsletters as well, because the newsletter creators put Google Analytics tags (utm_source) on their outgoing link to the hotlinking page, which I get as referrer as well. That way, I can see the number of times this link has been opened.

I think I'll get some popcorn.

[intari]

Possible solution :) :
Just use modified old trick from 1990s and return image saying something interesting about blog author and/or Ghost. Or use geolocation and return "right" political banner (like - if requesting user is in Gaza/Arab countries - show them extremly pro-Israel banner(with text like "site is hotlinking, this mean that YOU should enlist in IDF RIGHT NOW!"(pro-Israel version,appropriate ones for other places), if in Israel - pro-Gaza banner, in Ukraine - pro-Russian one,in Russia - pro-Ukrainian one, in USA - ramdomly select extremly pro-Binden/pro-Trump banners). This could result in this issue solved rather fast.

[JohnONolan]

This is a valid bug, thanks for pinging me - we’ll get it triaged and resolved.

[michaelnordmeyer]

@JohnONolan You might also think about making the ref parameter opt-in instead of opt-out, because not only is it a pushy way of adding visibility to linking domain, it also breaks some people's analytics by creating different URLs with different page views for the same post. Additionally, if someone shares this URL somewhere else, the ref parameter won't be matching the HTTP referrer anymore.