Lack of Restrictions for PDFs

[Psifour]

A continuation on the discussion regarding PDFs

Currently PDFs are not subject to the same restrictions as other MIME types. Specifically, we restrict JS in all other types (HTML and SVG) by the application of CSP. These restrictions greatly inhibit the following (purposefully or otherwise):

• Pointers - CSP configuration only allows referencing 'self' and as such prevents loading content from IPFS or Arweave
• XSS - Partial mitigation to a whole range of XSS vulnerabilities by the same mechanism as above
• Recursion - Without this protection Recursion #1082 is possible, but without structure/control/protections

I think we can all agree pointers being functional on anything that appears to be on Ordinals.com is detrimental. Currently it is possible to create a PDF that will link (pointers) to outside content, utilize potentially malicious XSS vectors, and/or pull content from other inscriptions without the need to fight the existing CSP. This can all be done in a way that, to casual users, will appear to be a 'standard' inscription.

With that in mind, I feel that my assessment of this being "outside the sandbox" is true unless we say that there is no intent to have a sandbox (at which point the existence of the CSP becomes an oddity).

Towards this, I believe that controls around PDFs are not only reasonable, but necesarry if we wish to remain isolated from Pointers, mitigate (not eliminate) XSS vulnerability, and have structured Recusion on Ord's terms instead of just however users can best circumvent the restrictions. I don't believe any restrictions on Inscribing PDFs is reasonable or justified.

[tyjvazum]

What potential mitigations do you propose?

[Psifour]

My proposed mitigations range wildly within the following options:

• Enforce all /content links to PDFs as a download instead of displaying in browser. This moves the ball fully into the users court and would, hopefully, trigger the part of users brains that knows not to blindly open downloaded files. This addresses the confusion that currently there is no user awareness in regards to if an inscription is html/text or a pdf until AFTER they have opened it. Drawbacks include greatly reduced UX.
• Disable PDFs from the primary Ordinals.com explorer while still including them in the index and count. Drawbacks include inadvertently restricting access to potentially meaningful content.
• Sandbox the PDFs using something like pdf.js with enableScripting set to false (assuming this hasn't been forked out as indicated by a PR removing it from their examples). Drawbacks include fully breaking any great uses of JS within PDFs.
• Add a disclaimer interstitial page the first time a user accesses a PDF /content page that warns them that PDFs will be loaded by their browser and are not subject to the sandboxing found in other data types. Drawbacks include slightly impacted UI/UX and a box that users will blindly click through before still being surprised that things weren't restricted in the same way as they have come to expect from other file types.

I am not convinced that there is an elegant solution that restricts them to exactly the same functionality as our html/svg pages, but I know that the current state doesn't seem optimal.

[mcn8]

It sounds to me like the 3rd option (sandbox) is the best here:

• Most meaningful content will likely not contain JS, so their functionality will be 100% intact
• If it happens to be a PDF with good uses for JS then the user can download it at that point to run it on their own
• This actually adds the benefit of being able to look over the file prior to downloading, making it easier to at least prevent downloading & opening obviously malicious files.

[casey]

Although it's true that PDFs are unsandboxed, it seems like this is mostly not an issue in practice, especially since they don't apply to the /preview page.