The difference is that you run only trusted native applications with the ability to check their source code, while you are visiting untrusted sites which often have obfuscated javascript.

I think that it would be a better comparison between a pdf file and the web: pdfs files can't do the same or more.

PDFs can run JavaScript too. Open this PDF in Chrome: https://raw.githubusercontent.com/osnr/horrifying-pdf-experi...

And I would argue it is harder for the average user to view the JavaScript inside PDFs: on the web just right click and choose Inspect Element right in the browser; for a PDF you'll have to use specialized tools to decode the myriad encoding schemes inside a PDF. The average JavaScript developer doesn't know how to extract JavaScript from a PDF.

While it works on Chromium it does not seem to work in xpdf, pdf.js nor any other pdf viewer that I tried. It seems that JS, flash, etc inside pdfs are proprietary, useless, and potentially dangerous adobe-only extensions that nobody else implements and nobody uses. It's just that Chromium happened to have a JS engine so they decided to let JS inside pdfs to be executed with a very constrained API (which can't do anything malicious probably - unless a bug is found in its JS engine).

My point still stands: I do not expect a pdf document to be able to do anything like the djsumdog's link and neither do most people. If a pdf document was able to do anything like that I would consider that viewer as broken.

> The average JavaScript developer doesn't know how to extract JavaScript from a PDF.

They could learn with a few google searches.

> you run only trusted native applications with the ability to check their source code

Is the "you" in this scenario Richard Stallman?