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