|Agreed, but I think we both agree that it is not the fact that the language is
|interpreted that provides the benefit, but because the transformative apsects
of
|the language on the local system are restricted in some way ...
|
then Sami wrote:
> Actually Java's properties are central to its security story. The fact
> that it doesn't allow pointer arithmetic and unchecked array accesses
> and compiles into interpreted bytecodes is what makes it possible to
> check whether a Java program is violating the language constraints. Once
> it can be shown the language constraints hold, it is then possible to
> restrict the runtime so that it can respect some security policy. Doing
> this sort of checking with arbitrary binaries would be very hard
> to do.
I'm assuming from the above that you were thinking I though it possible to
create a secure system by downloading artibary binaries. Obviously this isn't
the case and I'm actually amazed that you'd think I was !
I was thinking source supplied by the "server", then compiled on the fly and
executed on the client, and was just making the point that the **engine** on the
client was not necessarily the conventional interpreter everyone currently seems
to be thinking of ! I can (currently) think of no reason that a client-side
compilation system could be made provably secure.
-- Mike