Javascript JIT in web browsers

[Ilyes Gouta]

Kevin,

> Free Software is not just about availability of source code. (That's exactly
> why the term "Open Source" is misleading!) It's no use having the source
> code if you aren't allowed to legally do anything with it.

I did't claim that JS code is open source. 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. Heck, we can even change on the fly a JS piece within
the browser via a JS console (think Greasemonkey for FF, Chome's JS
console). Obfuscation however corroborates the latter aspect.

> Security against buffer overflow exploits comes from a security-conscious
> design.

That's what I meant by a (correct) specification and a compliant implementation.

>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). That's there is *still* room to make it safer and
I don't see why it has to be completely disabled, banned and shutdown.
Techniques such as process isolation (when running JIT'ed code), I/O
sand-boxing, lowered/restricted privilege resource access, etc. *do*
help.

> The web is a medium for information, not
> code.
> If you really want a platform for remote services (which I'm not convinced I
> want, I'd rather control the software I'm running), you need to help design
> a real cloud platform from ground up.

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.

-Ilyes Gouta

On Thu, Aug 19, 2010 at 3:22 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Ilyes Gouta wrote:
>> Since JavaScript has a client-side execution model and since the all
>> the JS scripts are downloaded in plain text format (even if sometimes
>> obfuscated) along with the html code, then can't we assume that JS
>> code is available in source format and hence can't be classified as
>> closed source programs?
>
> Free Software is not just about availability of source code. (That's exactly
> why the term "Open Source" is misleading!) It's no use having the source
> code if you aren't allowed to legally do anything with it.
>
> In addition:
> * Obfuscated code is not source code.
> * Those web apps also have lots of server-side code which is entirely
> secret.
>
>> the next-gen Web where most applications are going to be written in HTML5
>> and JavaScript and almost near-native execution performance is going to be
>> desired
>
> I want none of that useless crap, thank you very much! Applications should
> be written as applications, delivered through our package repository, in a
> compiled language. Web sites should just be web sites and have as little
> code as possible (ideally none). The web is a medium for information, not
> code.
>
> If you really want a platform for remote services (which I'm not convinced I
> want, I'd rather control the software I'm running), you need to help design
> a real cloud platform from ground up. The way the web is being abused as a
> software platform is really appalling. It's really not designed for that,
> and we have tons of ugly workarounds such as session cookies, AJAX etc.
> JavaScript JITs are a part of those broken workarounds.
>
>> Security comes from an implementation which is specification compliant
>
> Nonsense. Standards-compliance is completely orthogonal to security.
>
> Security against buffer overflow exploits comes from a security-conscious
> design. Converting untrusted code into native machine code and executing
> that is NOT a security-conscious design, it just begs to get exploited.
>
>> Techniques such as sand-boxing would also help a lot mitigating malware
>> and other security issues
>
> But an interpreter can enforce the sandboxing in a much more robust and
> failsafe way than a JIT.
>
>        Kevin Kofler
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>