Javascript JIT in web browsers

[drago01]

On Mon, Aug 16, 2010 at 1:15 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> drago01 wrote:
>> The times where javascript is only used for some fancy effects are
>> long over ... welcome to 2010 ;)
>
> Some web sites are indeed abusing JavaScript. Why should we promote this
> behavior? It is a vehicle for proprietary software, where people often
> aren't even aware they're using non-Free code, or just ignore the issue.
> See also http://www.gnu.org/philosophy/javascript-trap.html . A web site is
> not and should not be an application, an application is not and should not
> be a web site.

There is a difference between a website and web *application*.
Besides who is stopping me (or anyone else) from writing a free
software web app that uses Javascript? People have been and are doing
that all the time.
By your logic we should ban gcc, java, mono, python, perl, bash ... as
one can use them to create and/or run non free software.

Also you may be aware that javascript has its uses *outside* of the
web too (just like you can write apps in python you can do it in JS;
and having a JIT that speeds them up is definitely a plus).

>> The "problem" is fixable there is a patch that is being discussed
>> upstream to fix the issue and allow selinux memory protection it is
>> just not merged yet.
>>
>> Using a JIT is not a security risk by itself.
>
> Workarounds which make SELinux happy are still not as secure as sticking to
> a pure bytecode interpreter. Exploit code can still write to the memory to
> be executed, with ANY JIT, as this is how a JIT works. It's just that the
> writing has to happen through a different address space window as the
> execution, making the JIT harder, but not impossible, to exploit.
>
> So IMHO the right fix is to disable the JIT altogether.

This is *not* a fix. You can't solve problems by disabling features
and pretending they do not exists.

> But the proposed patch would still be better than the crappy solution
> implemented now just to "stick to upstream"

Yeah because forking a web browser which would end up with a more
secure experience than joining forces with upstream with the expertize
there and can deliver security fixes on time (which also apply to our
version).