> Am 2019-10-15 um 08:17 schrieb Marcin Borkowski <mb...@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. >>> 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. > 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. 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. 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. 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. Best, Hraban ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________
