[NTG-context] PDF viewer poll

Marcin Borkowski mbork at mbork.pl
Sun Oct 20 22:15:07 CEST 2019

On 2019-10-19, at 12:21, Henning Hraban Ramm <texml at fiee.net> wrote:

>> Am 2019-10-15 um 08:17 schrieb Marcin Borkowski <mbork at mbork.pl>:
>>>> Basically javascript can be limited to (1) setting annotation properties, like toggling layers or button renditions, and (2) some simple calculations (for forms). Constructing pdf runtime using javascript is pretty braindead (use html instead then).
>>> D’accord.
>> Of course you are aware that limiting a powerful language is not an easy
>> task?
> I am. But JS in PDF is completely different from PDF in browsers anyway (no DOM!), so they don’t need a complete interpreter and could have limited PDF scripting to a few commands, in JS syntax or anything else.

Fair enough, although I don't have an association JS <-> browser
ingrained so much - for me, JS is a general purpose language which
happens to be embedded in browsers, but also many other places.  Most of
my JS code runs either on a server (backend code) or in a development
environment (various, let's call it, DevOps-ish scripts).  Only now and
then I write JS for browsers, and then it is often crippled JS, full of
things like "var" (because old browsers etc.)

>>>> It is one of the puzzling areas to me: no problem in browsers and elsewhere but not in open source pdf viewers. It's not the most complex stuff so it probably indicates that no one cares much about these features.
>>> I wouldn’t say "no problem", because JS causes security problems everywhere.
>> It's not JS that causes problems.  Any other (powerful enough) language
>> not specifically designed with browser environment in mind could be
>> problematic here.  I guess that having Perl, Python or Ruby instead of
>> JS would create a similar set of problems.  (Lua might be an exception
>> due to its design and a possibility to whitelist functions for eval,
>> AFAIR.)
> Of course any programming language is a security risk. More so if it runs in an ubiquitous program like a browser. And since they created JavaScript for that, JS causes problems.
> When I read "Java runs on millions of devices" I don’t feel that’s good advertising, but it remembers me that each of those devices is at risk.

I like this approach:-).  There is also that old joke than "every time
you install Java it gets moved from another device to yours", since the
installer has been saying that "3 billion devices run Java" for almost
two decades now.

>> Just 2 cents from a JS programmer who actually thinks that JS is not the
>> worst Lisp dialect out there.
> I didn’t say JS is bad. For me it’s a necessary evil.
> I don’t think my beloved Python would be a better choice for client scripts.

Python is a worse Lisp dialect than JS, but still nice.  (Disclaimer:
i have only written less than 1000 lines of Python in my life.)

> Maybe Lua is, but every scriptable program is a risk.
> LuaTeX and write18 _are_ dangerous.
> It would be very easy to spread malicious TeX code, since everyone uses CTAN (LaTeX) packages without checking them first.
> But it wouldn’t come far, I guess, for it needs a while for a package to become known and in wide use, and that still means only in a subset of the (La)TeX community, where there are enough expert hackers who would find this malicious code.

Assuming that they would search for it.  I'm less of an optimist here.

> And you can count the people on one hand who would be able to publish a malicious ConTeXt module… Malicious code snippets in our wiki or ML also wouldn’t come far.

That's interesting.  It would be enough to have a "plain TeX virus",
probably.  I guess the main reason malicious ConTeXt code does not exist
(assuming this is the case!) is that it is not economically viable - the
ConTeXt community is too small.

> There was PDF malware (using JS or media stuff). There also was PostScript malware in its time. The latter didn’t make a lot of sense, except it could destroy RIP hardware. The RIP technician at the newspaper where I worked told me stories, e.g. there was an evil EPS (some faulty customer logo, no deliberate malware) that caused the deletion of important parts of the RIP software. At my time there was a PS ghost: somehow a page got installed on one of the printers and got printed at odd times. Reboot didn’t help, we never found the cause.

That's absolutely fascinating!


Marcin Borkowski

More information about the ntg-context mailing list