Re: Automatic Entry and Forms

>The first failure of science is the belief that one truly knows the scope
>of possibility within a system. Your credentials hardly shield you from
>making errors in judgement; I think this was why someone cited a quote from
>Napoleon.

I suggest that you read the actual quote. While you have made usefull and valid 
technical points the original post simply made patronising epithets "this dog 
won't hunt". There is little that is more calculated to irritate me intensely 
than for someone to make an assertion that technologists are unaware of the 
ethical implications of their work. There is a huge gap between considering such 
matters and putting them down in writing. 

There is also a very major problem in that different people apply different 
ethical standards. While I personnaly apply a utilitarian analysis in making 
personal ethical judgements I am aware that there are many who reject this 
position. I think that utilitarianism is flawed in that it fails to deal with 
the issue of free will and conciousness - I believe this to be the point which 
Nietzche is attempting to make. There are modern approcahes to this question of 
which the one I find most interesting are the communicative ethics such as that 
advanced by Habbermas. Rawls's provides an interesting presentation of the 
contractiarian position in communicative terms but I find that more convincing 
as method than as analysis.

While I could go into great detail on each of these points and indeed have, my 
book on the philosophical principles of the Web is currently at about 200 pages 
of which 50 consist of an attempt to construct an ethical framework on the basis 
of a modified ethics of will. I'm not keen to try to fit that into an RFC.


I would prefer to advance along the following ethical principles and not attempt 
justification :-

1) Each party on the Internet is equal.

2) The Internet is a public highway between private destinations. 

3) A party has a right to record details of their transactions for their
	own use.

4) A party has a right to expect that transactions will be kept in 
	confidence unless both parties have given informed consent to 
	the contrary.


>I think a weakness of the current proposal is precisely that it doesn't
>address the privacy and security issues that surround placing sensitive
>personal information in an accessible location on a computer.

This is a different concern to those raised previously by Robert, the concern
here is over a failure of an implementation rather than an abuse of a protocol. 
If a client is implemented properly it will take great care to ensure that it 
does not communicate a users private data to the outside without the users 
permission under any circumstances. 

Clearly there is more danger of information leakage if that information is 
stored on the machine than if it is not. There is plenty of such data which is 
already stored by a browser, history and bookmark data for example. Or to take 
the Rimm affair seriously, lists of subscribed newsgroups.


While Java and the like are relevant to this issue I think that the point must 
be very forcefully made that it is the responsibility of a mobile code engine to 
ensure that it does not compromise security. I have a number of serious concerns 
about Java security, I do not regard presence of demographic data in a client 
database to seriously worsen the situation. Such data is more than likely to be 
present on the client host in any case. A java implementation which divulged the 
form fields database would be equally likely to divulge a users email.

The first level of defense against such attacks is to note that a company which 
downloaded a Java applet which deliberately cracked the form fields database and 
uploaded information would be a clear breach of the US and other criminal codes. 
It is unlikely that such techniques would be used by commercial operations since 
a vendor of demographic data generally needs to convince the purchaser that the 
data is genuine by explaining how it was obtained. Otherwise it is impossible to 
eliminate statistical biases. Anyone purchasing such data would be an accessory 
to a criminal act.

This is not an adequate defense against private investigation agencies. Such 
agencies are frequently no above breaking the law. In such instances the only 
defense is a secure client implementation.


Just a word about Java, there are a number of concerns which have been raised at 
a series of meetings held at MIT. These include:-

1) Java applets use the content-type application/octet-stream and not
	application/java. This prevents a firewall identifying java applets
	and stopping them from being downloaded. No developer should 
	attempt to pre-empt the judgement of a firewall manager by assertion.

	Clients should immediately be modified to only execute properly
	identified applets. My recommendation would be for companies to
	refuse to purchase browsers enabled for any mobile code system
	without this feature.

2) There is no formal model of Java security.

	Programs without specifications cannot be wrong, merely suprising.
	Because Java does not specify what security it attempts to provide
	it is difficult to identify what a security breach entails.

3) There is no auditing facility.

	A user should be able to monitor when resources such as the disk or
 	network are accessed

4) Browsers are shipped with Java enabled. This contradicts the Orange book
	principle that code be shipped in a secure configuration. 

5) There are covert channels.

There is a paper due out of Princeton which goes into these concerns in detail. 
Until various holes have been patched I don't think it appropriate to go into 
details. 

Suffice to say I do _not_ believe that we should consider the dangers of Java in 
suggesting HTML extensions. If Java puts sensitive data stored on a machine 
running Java at risk then there is such a serious problem with Java that we 
should stop using it. 

I personnaly prefer to use a machine with an encrypted filestore and use a 
browser which either does not have a mobile code engine or have it turned off. 



>A 'next page' button on any web page is potentially a form
>submission. Does this proposal deal at all with the fact that any link is
>potentially an involuntary form submission containing hidden fields
>containing private information? No, it does not.

This would seem to argue for an interface model in which a user is prompted 
before a template is used to fill in form data. It might also be appropriate to 
prompt before storing the data away as well. 

Hidden fields would lie outside the scope of any template scheme. I see these as 
being a means for the server to pass information which it has generated to the 
forms processor. I don't consider these as "Input" fields, it is a pity that we 
didn't create a different class of tag (why is <TEXTAREA> a different tag and 
hidden fields not? - oh well).


>As I said before, I do share the Fear, Uncertainty and Doubt of the common
>lassitude over privacy issues. To hear someone state that because of their
>position within the security community they understand the issues or share
>my concerns, coupled with a proposal that doesn't even address these
>issues, it only reinforces my uncertainty.

I think you missunderstood why I took offense. Roberts message essentially said 
"look here is a techno-geek who does not understand the privacy problems". It 
made no statement of the concerns and misstated the proposal. While I am happy 
to discuss security and pricvacy concerns with people such as you, Murray who 
have raised legitimate technical points I am less inclined to enter into debate 
with people who start off with patronising comments about lack of security 
expertise.


My motivation in making the proposal was partly to avoid the proliferation of 
common log in schemes which are a far more serious threat in my view. How many 
people realise that when they give their demographic data to pathfinder it is 
linkable to all the sites using pathfinder? I prefer to provide a mechanism 
which makes it easy for a user to enter a subscription form at each site visited 
than to see more sneaky little schemes that pass the data about in a manner that 
the user cannot either control or understand.


	Phill

Received on Monday, 26 February 1996 11:20:59 UTC