[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE Scripting Interface
From:       Martin Konold <konold () suse ! de>
Date:       2001-07-19 21:28:28
[Download RAW message or body]

On Thu, 19 Jul 2001, David Faure wrote:

> > > Maybe this sentence holds the solution to the problem: the reason why Java
> > > applets are so different from Java applications (that is, untrusted applets)
> > > is because untrusted applets are run in a sandbox whereas trusted applets and
> > > applications are not.
> >
> > Who told you this??!!
>
> Hmm ? Martin, that's exactly right. The whole security manager thing, and difference
> between trusted (signed) and untrusted applets is exactly that. Anyway, this starts
> to be off topic for DCOP, it's really unrelated.

Till before NS4 and IE 4 if you have been running an applet in a browser
it was always running in a sandbox independent of signing.

Signing is described here:

	http://developer.netscape.com/docs/manuals/signedobj/trust/index.htm

The same applies to java applications (Signing a java app does not change
the fact that it is not running in a sandbox)

Or in other words the signing of java applets or applications is not
related to the sandbox in theorie.

Signing is generally a good mean in order to define authentic code but it
does not really help against malicious code. (Getting your stuff signed by
verisign is rather easy...)

Unfortunately what NS and IE did with version 4 was indeed a weakening of
security by trusting signed applets and let them penetrate the sandbox
instead strengthening security.

Yours,
--martin

[prev in list] [next in list] [prev in thread] [next in thread]