Add support for AcroJS/PDF scripting

[MichaelDeBoey]

Adobe PDFs can contain embedded JavaScript (AcroJS) for actions such as form logic, validation, and document-level scripting.
Ref: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/index.html

At the moment, we need Adobe Acrobat Pro to add actions/scripts to our PDFs.

As far as we know, pdf.js and Adobe Acrobat Reader are currently the only PDF viewers that support PDF JavaScript execution.

It would be very valuable if LibPDF could:

• support creating and modifying AcroJS actions/scripts in PDFs
• (once a viewer is available) expose and execute this scripting functionality in the LibPDF viewer

This would allow us to remove our dependency on Acrobat Pro and fully transition our PDF workflow to LibPDF.

Is support for PDF JavaScript something that is on the roadmap?

[Mythie]

Exposing the ability to execute scripts is always a pretty big risk, pdf.js typically recommends not enabling javascript execution as it has been the cause of multiple CVE's in the past.

It had been de-scoped for that reason but isn't something I'm entirely opposed to in the future, it just needs a safer way of actually handling it.

[MichaelDeBoey]

Thanks for the candid explanation. I completely agree that execution is the scary bit.

One pragmatic compromise that would keep this feature usable for us while limiting the attack surface is per-document, programmatic enablement:

• We would only enable PDF JavaScript for our system PDFs, i.e. documents that our backend generates and certifies/signs
• Those system PDFs must be locked/certified so they cannot be modified except for filling form fields (for example, a certification/permission that allows only form filling)
  Execution is allowed only when the document signature/certification verifies and the document has not been altered
• For all other documents (user uploads, arbitrary PDFs) JavaScript execution remains disabled by default

This keeps the runtime surface tiny and auditable.
We can still create and embed the AcroJS scripts at generation time (so we no longer need Acrobat Pro), but viewers would only execute scripts for a small, trusted set of (signed) "system" PDFs.

If helpful, we can require an explicit metadata flag or signed claim (e.g. allow_js: true in signed metadata) so the viewer only runs scripts when it can cryptographically trust the document.

[mbrevda]

Document Certification seems to helpful in conveying trust to runs scripts.

.

[dan-willett]

I agree that script adding and editing is a separate issue from script execution. I think it is very important to add the capability to add and edit scripts.

As far as other tools that allow the editing and creation of scripts, PDFill is an inexpensive software option for creating and editing scripts in PDF files.

As for viewers and editors that execute JavaScript in a PDF file, there are actually quite a few. The built-in viewer in Google Chrome executes JavaScript, as does the PDFXchange viewer and editor, to name a few.

As JavaScipt is an official feature of the PDF spec, in order to fully comply with the PDF spec, the ability to add and edit scripts in the PDF document is a necessary feature.