For anyone (like me) wondering why PDFs would need to support JavaScript in the first place, the main motivation/use-case appears to be validation and interactivity of embedded forms.
back
3 comments
I've seen javascript in PDFs be used for unintended exploits more often than every legitimate use combined. It's kind of like if JPEGs could run arbitrary code by design.
There are restrictions, but SVG is an example of an image file type that can run JavaScript (again, there are legitimate use cases for this).
> again, there are legitimate use cases for this
I'm curious: what legitimate use cases exist for embedding a turing-complete scripting language into an image format?
I guess this was specified in a time when nobody thought it would one day be possible to embed an SVG document in an HTML DOM and add animations and interactivity in a performant way there.
ninja edit: It's also from a time when W3C started to lose focus and authority.
It's amazing that SVG was so successful despite this mess and also the confusion potential of CSS in SVG.
Browsers ignore scripts in external SVG images. Don't know if that is for security reasons (JS sandbox unreliable) or because a full isolated JS context per image would be to expensive...
Wasn't there also a time where you could open a raw socket with SVG? SVG is very much from a time when we didn't know what the web was going to be or how it was going to work.
Every browser engine said no to that nonsense.
The core issue iirc was that one of the major use cases for SVG was map/navigation systems where a number of environments required fully standardized systems. But they didn’t want to say implement a full browser stack”, so they just came up with their own “networking api” that was just “sockets!”.
A lot of this work predated html5, and the subsequent rationalization of web specs such that (for example) the xhr API was not fully specified, and it was not a separate specification from the rest of the browser stack, so SVG couldn’t just do what they could (in principle) do now.
The SVG WG was not the most functional - i recall that something a subset of the committee did at one point was to after the end of one person’s work day they rescheduled a meeting to later “that day” (while they were asleep) and took a vote without them present.
A number of other choices were made to the detriment of the spec for specific use cases (the various performance profiles have fundamentally incompatible rendering behavior rather than gradual decay, etc)
Thanks for the explanations!
Funnily enough we did end up saying "implement a full browser stack" :/
I might be mistaken, but that sounds like a general XML-related security bug (of which there are plenty)
Compression: for some images, you can't use SVG's <use>, but a small script can generate the repetitive bits quite nicely. Also, aperiodic animation (e.g. a double pendulum): SGML animations can represent a few minutes, but don't try putting a few hours' worth in.
PostScript, the printer file format, is Turing-complete, for different reasons.
That's because SVG is actually a document format, that is mostly for vector graphics. SVG nodes even show up in the DOM and CSSOM.
as a general rule this would be to do generative graphics, user interactivity with the graphical elements, animations, superset of all these - games.
I knew a guy who wrote a PostScript document that was a map of the sky at that moment. If you rendered it an hour later it was different again. It used the `file` capabilities of host-based interpreters.
> I'm curious: what legitimate use cases exist for embedding a turing-complete scripting language into an image format?
Competing with flash?
SVG tries to be a lot of things, one of them was to be a full on interactive app.
Signature forgery?
There are "legitimate use cases" for just about everything imaginable on this planet because there will always be a user that goes "I spend all my day in X software wouldn't it be great if it could read my email/monitor my plants/talk to sales/..".
That's how cursed enterprise software develops email clients and chat services. Just say no.
I understand the motivation, but IMHO a PDF should be a static document, hence, something you can trust without worrying.
Since they can contain code, they can carry malicious code. PDFs have, in fact, been used for exploits. Meaning that you shouldn't really trust them. Which is a shame.
Iphones don't support JS in PDFs, but yet an integer overflow in image decompression code led to a zero-click imessage exploit.[1] So lack of explicit code support doesn't mean you can trust without worrying. Bugs can be anywhere. Iphones have been known to have crash-causing bugs in unicode-handling code.[2] So even just text could be a problem. Disclosure: I work at Google but not on Project Zero.
[1] https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
[2] https://techcrunch.com/2018/02/16/iphone-bug-telugu-unicode-...
> Bugs can be anywhere.
Yes. Bugs. Bugs can be fixed.
By-design (mis)features can't be fixed. The only way to fix them is by removing the feature.
Unless you're agreeing that JS-in-PDFs is a bug, you're conflating fundamentally different issues.
JS in PDF might be a mis-feature, but any security lapse is indeed a bug in the implementation (made doubly worse by firefox running the JS in a web context).
Yes, removing JS support would get rid of potential security exploits. It doesn't change the fact that said exploits rely on bugs in the implementation.
That's true, but it misses the point that scripting adds orders of magnitude greater complexity to the attack surface.
Fixing other kinds of bugs is fairly straightforward. Update your toolchain, update your dependencies, use the right dependencies, avoid undefined behavior, etc. Fixing scripting issues means participating in an active arms race.
There does seem to be a mismatch between what PDFs are mostly used for, and their full capabilities.
IMO it’s be nice to define a file format for PDFs main use (I think?), papers and documentation. PDF, scripting, but maybe the ability to zoom and pan figures?
Such a format exists and is called PDF/A: https://en.wikipedia.org/wiki/PDF/A#Description
PDF viewers can have a matching PDF/A mode where all non-PDF/A features are disabled.
In the engineering world outside software, our cad tools generate rich interactive functionality into PDFs, including but not limited to 3d models for those doing mechanical work.
I've known about those capabilities for a long time and I've always wondered: How commonly is that used? For what use case(s)? What makes PDF the format of choice for that purpose and not, for example, a CAD file? What PDF apps are popular for creating and using those files?
pdfs are categorically not the appropriate medium for this.