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.kof...@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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
