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