ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Christopher Browne]

On Oct 30, 2007 5:22 PM, Ian Petersen <ispeters-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On 10/30/07, D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org> wrote:
> > | From: Ian Petersen <ispeters-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
> >
> > | I think you and Lennart have both raised basically the same point.
> >
> > No, I don't think so.
> >
> > | You're pointing out that the new language is more complex, right?
> >
> > No, I didn't say that.  I have not studied the language and have no
> > opinion on that.
>
> I seem to have put my foot in my mouth, so I'll try to be brief.
>
> > I was only challenging your analysis that could be summarized as: the
> > security issues for all Turing-complete systems are identical and
> > hence if you have solved them for one, you have solved them for all.
>
> I think your summary is stronger than what I intended to say (because,
> for example, the lack of buffer overruns in Javascript means its
> security issues are probably different that the issues that C faces),
> but maybe not.  I believe that the existing Javascript interpreter can
> simulate the new language, so I don't think the new language is
> introducing new problems*.  I don't know what is implied by "all
> Turing-complete systems", so I don't know what the security issues are
> for an arbitrary member of that set.

Generally speaking, claims about "all Turing-complete systems" are
about the notion that a Turing Machine
(http://en.wikipedia.org/wiki/Turing_machine) is considered powerful
enough to compute anything that is computable.  The basic TM is a
really rather simple device, but since there is the strong
computational result, the argument can be made that no language is
*essentially* more powerful at computing than a TM, and therefore that
no may be FUNDAMENTALLY more powerful than any other.

In one sense, there's truth to that, and an important truth, in that
the notion that there is some equivalence between different languages
implies some likelihood that if there are fundamental problems with
one, they may map onto fundamental problems in another.

There is also some essential falsity to it.  While all computer
languages (of some level of sophistication) are essentially able to
compute the same things, they are NOT all equal in how convenient or
efficient it may be to compute things.
- If working with vector-based problems, APL may be somewhat preferable.
- If working with problems that heavily use strings, then it is likely
that languages like C will be less than preferable, and that languages
that offer strings as "first class objects" like SNOBOL, Icon, Awk,
and their descendants will be more convenient and efficient to use.
- If working with rule-based problems, guarded Horn clauses are a
useful abstraction, and languages similar to Prolog are likely to be
preferrable.

There is a security side to this, where C happens to be particularly
vulnerable in certain ways, and those languages with "first class
strings" tend to lack those specific vulnerabilities.

> > |  And
> > | Lennart is pointing out that an interpreter for a new language is
> > | complex.
> >
> > I don't think that that is a fair summary of what he said.
> >
> > I understood him to say new untested code is worthy of more distrust
> > than old tested code.
>
> Yes, you're right.  I focussed on the special case of a new
> interpreter and Lennart's point was broader than that.

On the other hand, if the new version of JavaScript happens to have a
more regular/orthogonal design, it may be the case that it is easier
to construct more comprehensive tests for the new version, which would
tend to point to the newer code having the potential for being
*better* tested, and hence less worthy of distrust.

I don't know if that is the case, though; I have no indication at
present as to whether that is the case or not.

> * Lennart was right when he said that a new language implies a new
> interpreter, which very likely implies new bugs so, in a way, a new
> language is introducing new problems.  However, I have to believe
> that, when designing a language, you assume that the interpreter will
> work.  Bugs in the language are different from bugs in an arbitrary
> interpreter for that language and, more to the point, Walt was
> denigrating the _language_, not its interpreter.

To be more exquisitely precise, I would separate this into two terms:

1) The language design and specification, and

2) Specific implementations of the language.  (Interpreted or otherwise.)

It is quite worthy of separation because there are very different
kinds of assertions that fall out of those two aspects.

Problems that are found in the design/specification will be intrinsic
to ALL implementations; if the language is misdesigned in some
important way, that can only be rectified by a refusal to comply with
the specification.

In contrast, problems found with implementations have much greater
room for action, and fundamentally better opportunity for repair.

But stepping back to the real problem, I don't think any of this
actually relates to the security problem that Walter Dnes is concerned
about.

His objection is to the fact of there being a JavaScript processor
operating as part of the web browser in the first place.

Changes to the language design or to a given implementation are
irrelevant to that.
-- 
http://linuxfinances.info/info/linuxdistributions.html
"...  memory leaks  are  quite acceptable  in  many applications  ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists