[RunSet]

A more meaningful security boundary might be making HTML viewers' ability to run arbitrary code an opt-in feature, rather than opt-out.

Imagine if every PDF viewer included a virtual machine that ran in the background while viewing the document.

[RodgerTheGreat]

I have some bad news for you about PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa...

See also: https://rawgit.com/osnr/horrifying-pdf-experiments/master/br...

[saurik]

Even better, every font renderer does! A couple of the PDF-based jailbreaks for iOS were actually bugs in the virtual machine used by font renderer to allow fonts to do programmatic hinting, and the PDF only really existed as a container to deploy the font and force it to deterministically render exactly what was required.

[RunSet]

I intuitively expected some trash like that from Adobe which is why I wrote "every PDF viewer" and not "Acrobat Reader".

[capitainenemo]

His "breakout" demo works in Chrome's viewer as well (and obviously FoxIt).

[warkdarrior]

Opt-in code execution is not a meaningful security mechanism because users do not have the expertise or information to answer a prompt like "Do you want to allow this web page to run code?"

[a1369209993]

Prompts are not opt-in. Opt-in is moving the mouse to (say) the lower-right corner, clicking on the NoScript icon, and selecting "Temporarily allow example.com".

That's not a panacea, but it at least raises the bar from "get people to even briefly look at your attack site", to "come up with a at-least-vaguely-plausible excuse why your site needs to be handed a remote code execution vulnerability in order to function".