[Sugar-devel] Deployment feedback braindump

[Albert Cahalan]

On Wed, Aug 12, 2009 at 10:16 AM, Lucian
Branescu<lucian.branescu at gmail.com> wrote:
> 2009/8/12 Bernie Innocenti <bernie at codewiz.org>:
>> El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió:

>>> JavaScript-in-PDF is mostly a joke and a big security risk. It's not
>>> something to be relied upon.
>>
>> It might be useless, but I don't see why it should be more risky than
>> Javascript in web browsers, which everybody happily accepted without
>> much thought.  Is JS in PDF even allowed to make HTTP connections?
>
> JavaScript in PDF is more risky because the sandboxing isn't as mature
> as the one in web browsers. It should theoretically be at least as
> safe, but in practice it isn't. This is mostly a problem with adobe's
> implementation, which is an absolute train-wreck, but other
> implementers without browser sandboxing experience might repeat some
> mistakes.

Anybody sane would just grab a mature engine from a browser.

The recent supposed JavaScript problems in Acrobat are nothing
more than heap spraying; there are at least two non-JavaScript ways
to do that. The exploit was recently redone w/o any JavaScript.

Note that PDF, being essentially postscript, already comes with
a full programming language. That's what postscript **is**.

>> How do you dubmit the form?  By HTTP?  Does the PDF reader tell the user
>> when it's going to make this connection?
>
> You would submit the form by sending back the completed PDF file. It's
> a bit awkward, but it works.
>
> Ideally, people should be using HTML forms, those are made to be
> easily and seamlessly submitted.
...
> In any case, PDF is a good presentation format. Why make it
> significantly more complex for small-to-none improvements to its main
> purpose?

PDF forms often look attractive. HTML forms normally look ugly.
This is because PDF is a good presentation format. HTML is not.

Printing a PDF form to fill it out the old-fashioned way is reasonable.
You can even fill most of it out, print it, and then sign it or stamp it.
With HTML this really isn't practical.

In the case of math worksheets, the child really needs a way to
scribble on the document. This is for handwriting practice and to
allow arbitrary free-form drawing and layout. PDF can provide this,
either via printing or via wrapping extra postscript code around the
document. To do this in HTML you'd have to write a custom app
in JavaScript, Java, or flash -- none of which is really HTML at all.