Re: Mindshare and Java

At 10:47 PM 4/24/96 -0700, Rich Graves wrote:
>I agree that the major innovation, and cypherpunk opportunity, of Java is
>in its cross-platform nature, not its vaunted ability to run untrusted
>code safely. I'm sorry, I'm just not interested in running untrusted code. 
>Give me digitally signed code that I can trust, or for which the author 
>can at least be held accountable, and I'll be happy. 

I, for one, am interested in running untrusted code.  If I can run
untrusted code, I can greatly reduce my exposure to Trojan horses and bugs.
 It bothers me that if I run Microsoft Word, it can trash my MacWrite
files.  Even if I get these programs from reputable dealers, in original
shrink-wrap boxes, so I have good reason to believe I know who the author
is, I am still exposed to these problems.

I should note that Java's one-straitjacket-fits-all approach to running
untrusted programs is not adequate to satisfy my desires.  However, it is a
start, and it does run in todays complex Input Output Control Systems that
have been misnamed "Operating Systems".  (If it can't enforce a security
policy, it isn't an Operating System.)

I would rather use technological means to prevent damage than legal means.


------------------------------------------------------------------------
Bill Frantz       | The CDA means  | Periwinkle  --  Computer Consulting
(408)356-8506     | lost jobs and  | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA

On Thu, 25 Apr 1996, Bill Frantz wrote:

> At 10:47 PM 4/24/96 -0700, Rich Graves wrote:
> >code safely. I'm sorry, I'm just not interested in running untrusted code. 
> >Give me digitally signed code that I can trust, or for which the author 
> >can at least be held accountable, and I'll be happy. 
> 
> I, for one, am interested in running untrusted code.  If I can run
> untrusted code, I can greatly reduce my exposure to Trojan horses and bugs.
>  It bothers me that if I run Microsoft Word, it can trash my MacWrite

Both policies make sense in different circumstances; however,  
refusing to run unsigned code, even though it reeks of FUCKING STATISM is 
easier verify, and harder to circumvent; We're experimenting with both 
approaches in Solid Oak (one classloader that rejects unsigned classes, 
another that works with the security manager to use the signed IDs to 
make policy decisions where necessary. That approach is the more 
flexible, but it remains vulnerable to flaws in the policy manager if it 
is somehow possible to do naughty things without going through the 
security manager. If you require even untrusted code to be signed you at 
least have a target-id to send to blacknet for attitude adjustment.

One thing that could be retroactively added to the vm pretty easily would 
be the ability to add capability requirements to methods, and have the 
class loader automatically generate code to check for those requirements 
before executing the body of the method

Simon

---
They say in  online country             So which side are you on boys
There is no middle way                  Which side are you on
You'll either be a Usenet man           Which side are you on boys
Or a thug for the CDA                   Which side are you on?
  National Union of Computer Operatives; Hackers, local 37   APL-CPIO

On Thu, 25 Apr 1996, Simon Spero wrote:

> On Thu, 25 Apr 1996, Bill Frantz wrote:
> 
> > At 10:47 PM 4/24/96 -0700, Rich Graves wrote:
> > >code safely. I'm sorry, I'm just not interested in running untrusted
> > >code. Give me digitally signed code that I can trust, or for which
> > >the author can at least be held accountable, and I'll be happy. 
> > 
> > I, for one, am interested in running untrusted code.  If I can run
> > untrusted code, I can greatly reduce my exposure to Trojan horses and bugs.
> >  It bothers me that if I run Microsoft Word, it can trash my MacWrite
> 
> Both policies make sense in different circumstances; however,  
> refusing to run unsigned code, even though it reeks of FUCKING STATISM is 

It doesn't have to, reek I mean. By "held accountable" I mean by me, the
user, not the coercive power of the FUCKING STATE.

For me, the digital signatures would not be the imprimatur of "good, safe
code." The digital signature would mean, "Rich Graves <rich@c2.org>
accepts blame for this code." Or "This code is an official (or whatever
the unofficial official unofficial word would be) part of the GNU
project." Or "The Black Unicorn nym says 'Two Thumbs Up.'" Or "This is an
accurate copy of the code discussed on comp.windows.emulators.wine." 

In my fantasy world, signatures would be verified by the web of trust, not
the FUCKING STATE or FUCKING MICROSOFT. 

I guess "trusted" isn't the right word, thanks. I don't "trust" anything
that comes from Microsoft to be bug-free. I do expect it to be free from
exogenous viruses and trojans, though, so that the bugs would be
reproducible, and have a chance of being fixed.

In my fantasy world, I'm not asking you to verify signatures every time
you run something. Maybe you can tune how often you want stuff checked, so
you have a tradeoff between security and performance.

Sort of like COPS or Tripwire, but transparent to the user.

-rich

On Thu, 25 Apr 1996, Rich Graves wrote:

> In my fantasy world, I'm not asking you to verify signatures every time
> you run something. Maybe you can tune how often you want stuff checked, so
> you have a tradeoff between security and performance.

In SolidOak, the verification is more or less free of charge, as it runs
the signature code in a separate low priority thread, which often gets to
complete during network induced latencies when fetching sub-classes, which
can be initiated on class download before the code is instantiated.It also
allows multiple classes to verified with just one PKOP, so the cpu cost 
is amortised over a lot of stuff

Simon

---
They say in  online country             So which side are you on boys
There is no middle way                  Which side are you on
You'll either be a Usenet man           Which side are you on boys
Or a thug for the CDA                   Which side are you on?
  National Union of Computer Operatives; Hackers, local 37   APL-CPIO