> I have said it many times before publically, and I'll restate it here, IMO
> ActiveX is not secure, IMO it is not intended to be secure, IMO Microsoft are
> misleading people with their statements, IMO third-parties are going to make
> ActiveX-bearing environments secure against ActiveX's insecurity.
>
> Clear enough for everyone?
Thank you. We are in violent agreement.
The real problem with Java is that they took a general purpose language with
a fast lightweight interpreter, and tried to secure it by keeping dangerous
instructions away from the interpreter. The way to secure a system like this,
really, is to simply not provide any path in the interpreter to dangerous
things. This means (a) your interpreter has to be heavier, because you need
to do more bounds checking and the like at that level, and (b) your runtime
is going to be larger, because you can't implement stateful mechanisms and I/O
in it because it doesn't include any in the language proper.
That's the approach Safe Tcl uses. It builds an interpreter that simply
doesn't have any "dangerous" commands in its symbol table, so there's no
mechanism from Tcl to access routines like "open".
In any case, the problems in Java don't indicate problems with "sandboxing"
in general.
References:
|
|