Content link and page no longer available

[gmart7t2]

Since #4295 I no longer see the "content" link on the /inscription pages, and if I try to view the content page by typing the url manually I get a CloudFlare error:

[switch-900]

I am getting the same. And i know any others are, too. Screenshot_20250327_211640_Chrome.png

[billpan69]

Getting the exact same issue since yesterday.

[gmart7t2]

To make matters worse, some inscriptions only work via the /content link, giving an error when visited using the /inscription or /preview links

For example, this used to work, but now gives a CloudFlare error:

• https://ordinals.com/content/80085ebd72934471366c1f91a2885619b45f0f5de1ef2291e8a92553b825fc33i0

Using /preview instead gives an error about local storage not being available:

• https://ordinals.com/preview/80085ebd72934471366c1f91a2885619b45f0f5de1ef2291e8a92553b825fc33i0

The inscription works on other ord servers without the new CloudFlare restriction:

• https://tx.ordstuff.info/content/80085ebd72934471366c1f91a2885619b45f0f5de1ef2291e8a92553b825fc33i0

[elocremarc]

the terminal is broken

this honestly broke my heart today
8f70ff05e1dcddc8b3db3ae60cb00860fefb036725a3cbdad692999a9b767aefi0

[UrbanBorNovak]

[UrbanBorNovak]

[brianorwhatever]

@casey @raphjaph this is relatively serious.. can we get some eyes on this?

[snap608]

Verified and fixed in v0.23.1 for me.

[casey]

Yooo, what's up guys! Sorry for the radio silence on this! The reason we didn't communicate about this change was because it relates to a potential spoofing attack. The attack is:

1. Attacker publishes an inscription with ID XYZ which uses the JS History API to change the URL path to /mint
2. User clicks on a link to https://ordinals.com/content/XYZ
3. User sees that the path is now https://ordinals.com/mint
4. User thinks that this is a mint by the owners of ordinals.com, sends BTC, gets rekt

This was a scenario that I hadn't thought about, so I thought that it would be worth trying to mitigate it. In #4258, I added a preview page for iframe content (HTML and SVG) which wrapped inscription content in an outer page with an iframe pointing to /content. This prevents the attack, since now the inscription cannot change the top-level URL.

However, and this is the part that I didn't anticipate, this broke a lot of inscriptions that rely on being served on /content` directly. This includes things like local storage, and other browser APIs which aren't enabled inside of a sandboxed iframe.

To be clear, this didn't break any inscriptions which worked in /preview iframes, either shown as thumbnails or on /inscription. This only broke inscriptions which relied on the user manually visiting the /content page.

I experimented with some fixes, but the reports in this thread, as well as some DMs on Twitter, convinced me that there was going to be a long-tail of broken inscriptions, and that we should just revert the change, and give up on mitigating this attack, which I did in #4315, which I also pushed out into a release, 0.23.1.

Unfortunately, given the current setup, this means that our policy for ordinals.com has to be "nothing on ordinals.com can be trusted". This limits what we can do. This means that we can't offer features which have any degree of trust, or even which rely on users being able to believe that the content on ordinals.com is accurate to any degree.

If we do want to change this, the plan will be to host all inscription content, as well as recursive endpoints, on a separate domain, similar to how github.com hosts user content on githubusercontent.com. This won't break inscriptions, since nothing will change about how they're served, just that they're served from a different domain, so that even if an inscription changes the path to /mint, it will be susordinalsbullshit.com/mint, and if you send bitcoin there I don't know what to say.

Anyways, this is closed as fixed, since the change was reverted.

Thank you for the reports, and sorry for the breakage!