[E-Lang] Java 2 "Security" (was: Re: Welcome ChrisSkalkaand ScottSmith of Johns Hopkins)

Jonathan S. Shapiro shap@cs.jhu.edu
Sun, 21 Jan 2001 02:12:32 -0500

> There are two kinds of attacks in
> such a system -- those below the level of abstraction, which prevent the
> physical embodiment from faithfully realizing the abstraction, and those
> above this level, which can only utilize logical errors in the mathematical
> expression of what the system is supposed to do.

Interestingly, the credit card identity checks fall into both
categories. They exist primarily to work around the fact that the card
is forgeable. Usually I only need to know the number. In fact, I would
argue that because of this flaw a credit card isn't a capability at all
- it's an identifier. The notion that you must reveal the identifier in
order to use the capability breaks the model in a fairly major way. If
credit cards actually *were* capabilities we wouldn't be having this
discussion! (Hah! Take that!.. No, no. Sit, Ubu. Good dog).

A compounding problem is that in the online and telephone environment
credit cards work by proxy. You tell the person at the other end the
number. They do the purchase on your behalf. Actual thefts of the cards
themselves is an extremely rare event, and most of the personal metrics
methods don't work against that case -- given the name on the card it's
trivial to look up most of the personal information you need.

I think that Scott has raised a valid view that security is cost-based.
Actually, I have held this view for a long time and was somewhat bemused
to be hoist on this issue. I think that as a mental shorthand there are
some costs that we categorize as "too high to break" and we subsequently
treat these topics (at least casually) as secure in a black and white

Nonetheless, the personal information test is a terrible security
mechanism. To explain why I shall need to add a taxonomy for security
measures, which I am still thinking through.