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
participants (3)
-
frantz＠netcom.com -
Rich Graves -
Simon Spero