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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
