> Is this using the browser's own JS engine?

This issue makes it seem that Components.utils.Sandbox is used when included in firefox, which would be the browser's own JS engine (but confined to a sandbox), and quickjs in other settings (say a website). https://github.com/mozilla/pdf.js/issues/12487

But I can't find Components.utils.Sandbox being referenced in the code on github. So maybe they decided to use quickjs for all use cases? The issue with quickjs is that it's written in C which is an unsafe language. wasm has bad binary security [0] so exploits are easier to create given some memory safety violation. The environment that calls the wasm is extremely privileged compared to random websites, so if a wasm exploit could convince the environment to do something, it would be major trouble.

[0]: https://www.usenix.org/conference/usenixsecurity20/presentat...

You can't use plugins like NoScript with PDFs on Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1454760

interesting, could you embed a pdf into a webpage that has some JS which triggers automatically? Even if you have noscript?

I don't want to say so authoritatively, but I don't believe so.

This desperately needs an option to disable PDF js.

You can create a Policy File on Linux named "/etc/firefox/policies/policies.json" to disable pdf through out the system, here is a snippet for just pdf:

{ "policies": { "PDFjs": { "Enabled": false }, "DisableBuiltinPDFViewer": true } }

See:

https://support.mozilla.org/en-US/kb/managing-policies-linux...

I see pdfjs.enableScripting in about:config options. Have to check whether that option disables this scripting after I get the new version.

NY state tax forms have all sorts of verifications and automatic calculations that I assume are implemented using PDF JS. Previously you had to use Adobe Reader, hopefully this means I can use Firefox now.

It does get used for interactive forms. The native PDF form handling is more simplistic.