ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Marcin Borkowski <mbork@mbork.pl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: PDF viewer poll
Date: Sun, 20 Oct 2019 22:15:07 +0200	[thread overview]
Message-ID: <87h843goms.fsf@mbork.pl> (raw)
In-Reply-To: <C3078F30-ADD8-49AD-B2FF-298A4F98E74C@fiee.net>


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

>> Am 2019-10-15 um 08:17 schrieb Marcin Borkowski <mbork@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!

Best,

--
Marcin Borkowski
http://mbork.pl
___________________________________________________________________________________
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
___________________________________________________________________________________

  parent reply	other threads:[~2019-10-20 20:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-13 10:43 Henning Hraban Ramm
2019-10-13 10:47 ` denis.maier
2019-10-13 14:50 ` Rudolf Bahr
2019-10-13 15:26   ` Henning Hraban Ramm
2019-10-13 15:50     ` Pablo Rodriguez
2019-10-14 17:09     ` Greedwolf DSS
2019-10-13 16:49 ` Pablo Rodriguez
2019-10-13 18:02   ` kaddour kardio
2019-10-13 18:28 ` Hans Åberg
2019-10-14  7:58 ` Taco Hoekwater
2019-10-14  9:17 ` Hans Hagen
2019-10-15  4:42   ` Henning Hraban Ramm
2019-10-15  6:17     ` Marcin Borkowski
2019-10-19 10:21       ` Henning Hraban Ramm
2019-10-19 10:51         ` Hans Hagen
2019-10-19 11:06           ` Henning Hraban Ramm
2019-10-20 20:15         ` Marcin Borkowski [this message]
2019-10-21  8:21           ` Hans Hagen
2019-10-15  8:11     ` Hans Hagen
2019-10-15  8:12     ` Taco Hoekwater
2019-10-15  8:21       ` Hans Hagen
2019-10-15  8:25         ` luigi scarso
2019-10-16  8:02   ` luigi scarso
2019-10-14 16:55 ` Marcin Borkowski
2019-10-15 15:40   ` Benct Philip Jonsson
2019-10-15  4:26 ` Alan Braslau
2019-10-15  4:58 ` Hamid,Idris
2019-10-19 19:27   ` Henning Hraban Ramm
2019-10-15  5:00 ` Otared Kavian
2019-10-15 11:58 ` luigi scarso
2019-10-16  9:30 ` context
2019-10-13 18:21 Damien Thiriet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h843goms.fsf@mbork.pl \
    --to=mbork@mbork.pl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).