Some comments on the topic of security

Norbert Schmidt (Norbert_Schmidt@ka.maus.de)
Sun, 30 Nov 97 21:22:00 +0200

From: Norbert_Schmidt@ka.maus.de (Norbert Schmidt)
To: java-security@web2.javasoft.com
Subject: Some comments on the topic of security
Date: Sun, 30 Nov 97 21:22:00 +0200

Hello java-security team.

Before I bother you with my problems here are some information about
myself:
I have been programming since almost 20 years. After some first steps at
school I started working part time with CP/M-80 machines (assembler,
basic, pascal, later C) while I studied computer sciences at a local
german university. Later I became self employed and finished my degree. I
have been programming DOS games for several years and now I'm working with
Java (1.0.2) to create applets (mostly games) for use on the internet. (If
you want more details, I'll be happy to supply them.)

My problems may seem petty to you. But please take into account that
over here in Germany e.g. internet accounts and connections are rather
expensive compared to the US.

I'm now working under windows 95 and most of the currently popular
browsers show a really paranoid behavior concerning Java. Only Netscapes
3.01 seems to allow at least the reading of local files for a locally
loaded applet. With most of the other browsers it isn't even possible to
test an applet which loads data on a standalone computer.

Now I wanted to develop an Applet (maybe 50 KB) that any user should be
able to download and use offline to edit and store some data locally on
his machine. Later he would send the results of his work back to a CGI
script on the internet server. It works fine with the applet viewer. But
unfortunately normal users in Germany don't have the JDK, just a java
enables browser. And the storing of data won't work on any of those I
tried out. Since it is supposed to run on as many browsers as possible,
Java 1.1 is not a valid option yet. So what's left? I will put the data to
store coded in a TextArea which the user has to transfer via cut and paste
to a disk file while the loading must be done with the same degree of
usability.

You could justifiably say that the implementation of a SecurityManager is
the business of the browser manufacturer. But look at the results: Hardly
any thought went into it except a "deny anything local" policy.

I was looking forward to the more elaborate security concept promised for
Java 1.1. Frankly, I'm very disapointed. The concept itself is nice enough
but it seems to come from an ivory tower without caring for practical
aspects.

First, it's too cumbersome and expensive for practical use. Expensive?
Maybe not for developers from the US. But take a look at what those
"certification agencies" charge any small developer from elsewhere!
Cumbersome? Well, after a first long glance the documentation I'm pretty
sure I will hate to go through all the motions neccessary to create a
signed applet after each small change for a new test.

Second, where is the real security for the user? For a programmer it's
nice to know that his applet hasn't been tampered with. But where's the
beef for the user? The only security such a signature provides is an
increased probability to locate the author of a destructive applet. That's
great if the user and that programmer live in the states - with a good
lawyer you might sue his pants off. In Germany: forget it! And I wouldn't
trust any local governmental ageny with my security why should I trust a
foreign goverment or corporation? (Would you trust a M$ signed ActivX
component? I may be paranoid but the only person I can fully trust
is me. ;-))

What I expected was something less compilicated but more secure. E.g. a
simple SecurityManager for applets that will pop up a dialog window for
the user to acknowledge whenever the applet wants to execute a
potentially insecure method. Just like browsers can do for cookies. Since
this would become too annoying for daily use there should also the
possibility to set sensible defaults depending on the origin of the applet
and editing the settings for specific applets kept in a database of known
applets. And when acknowledging such a request there should be options
like: (this applet/all applets from this source/...) in combination with
(once/for this session/always). More differenciation for local access
would be to create a sand box directory - maybe applet specific - where
applets may work without asking additional permission while access to the
rest of the local storage should still be possible but with tougher
security.

Greetings, Norbert Schmidt

(No mail > 16K per day)