ECMAScript ("Javascript") Version 4 - FALSE ALARM

Tue Oct 30 18:41:47 UTC 2007

On October 30, 2007 02:11:51 pm Christopher Browne wrote:
> 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.

As the network (broadly defined) becomes more and more the center of 
computing, one way of mitigating against (at least in part) those 
concerns is to use established frameworks/libraries like Dojo, jQuery, 
scriptaculous, GWT etc. Much of the problem (IMHO) with Javascript 
implementations is that every site seems to have its own custom written 
solution. Likely that is because there haven't been many javascript 
libraries available historically? I think those crossbrowser compatible 
frameworks are changing things for the better as they gain more 
widespread usage and acceptance.

However, using an established library on a website should in no way 
diminish the broad concern of clientside browser security that Walter 
points out. But using one (or more of course) could at least create a 
middle way, where users can trust the library/site?

Perhaps a browser extension to sign or verify known 
scripts/libraries/functions would be useful? Probably something 
Greasemonkey could do.

I guess the issue is one mostly founded on mistrust: users don't want to 
risk executing clientside code for fear of compromising their systems, 
and developers don't want to run (some) serverside code for fear of 
compromising theirs, or reducing their ability to scale said system 
because of processing constraints.

Jamon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://gtalug.org/pipermail/legacy/attachments/20071030/c93388a6/attachment.sig>