Javascript JIT in web browsers

[Kevin Kofler]

Ilyes Gouta wrote:
> It's just that, we all being able to pull JS code in plain text from a
> given server, from any place on the world, doesn't really help classifying
> that code as a closed source.

Sorry, but you're arguing against a strawman: I didn't claim that the code 
was "closed source", I said that it's non-Free, which it is.

>> Security against buffer overflow exploits comes from a security-conscious
>> design.
> 
> That's what I meant by a (correct) specification and a compliant
> implementation.

And here too, I'm afraid you're missing the point. The same specification 
can be implemented in 2 perfectly compliant ways, one being secure and one 
insecure. A JIT is inherently insecure.

>>Converting untrusted code into native machine code and executing
>> that is NOT a security-conscious design, it just begs to get exploited.
> 
> Still, it's can be correctly designed to really lower the risk (or
> even eliminate it).

I don't believe the risk can be eliminated entirely. There will always be 
unacceptable risk if you execute native code generated at runtime from an 
untrusted source.

> It's changing. HTML5 and JS are going to be the front-ends for such
> remote services provided by those cloud platforms. And these are the
> standard way (vs. Adobe's Flash for example) to deliver a rich
> experience to the end-user, right in his browser, and IMHO we should
> support that.

Well, that's not what HTML, nor the underlying HTTP, was designed for. I 
don't see it as being an appropriate platform for software at all. (And I 
don't see plugins such as Flash as being the solution either. I believe this 
needs a completely different protocol, e.g. NX is something going in that 
direction.)

And IMHO, as a Free Software distribution, we should do all we can to 
promote Free Software installed on the end user's machine where he/she has 
full control (freedom!) over the software rather than remote services, web 
or otherwise.

        Kevin Kofler