[E-Lang] Re: Old Security Myths Continue to Mislead
Jonathan S. Shapiro
Sat, 4 Aug 2001 13:44:36 -0400
> Jonathan Shapiro has attempted to relate the high-points of a private
> e-mail discussion between the two of us. I respectfully disagree with
> Shapiro's characterization of my opinions. As our discussion has been
> private, I'll leave it at that.
Hmm. I won't respond in kind, but neither can I concede down with integrity.
Rather than mischaracterize Dan any further, I have decided with great
reluctance to let him speak for himself by publishing a very small excerpt
from our email exchange. I have decided not to publish the entire exchange
at this time, though given the exchange I'm sorely sorely tempted.
Publishing this excerpt violates Dan's post-facto request that I keep the
entire exchange private. While I disagree with him about the expectation of
privacy in the exchange, I see no reason to disclose more than I must, and I
would like to respect his wishes to the extent that scientific
responsibility permits me to do so.
I am taking this step for the following reasons:
1. It is my view that as scientists we are obligated to promptly acknowledge
errors in our work (or to refute them). Acknowledging an error of claims
privately and then disavowing that acknowledgement publicly is not, in my
view, responsible behavior.
2. The particular errors are causing real cost in the real world. They
appear to be contributing to erroneous understanding and consequent design
errors among the Mozart group. I have also seen this paper cited elsewhere
in support of the claims of this one section.
3. Dan has declined three or four requests that he do this himself.
4. Unless prior agreement of privacy exists between the participants, there
is no obligation in law or custom to keep mail private. [Believe it or not,
this issue has actually gone to court in connection with republications of
"collected letters." I think it may have been the supreme court, but my
memory on this is fuzzy.]
Under lesser ircumstances, I would not take the step of publishing the
correspondence, but the current outcome cannot be tolerated by scientific
Dan is under great load at the moment, and I do not believe that his
decision in this matter, made under stress, is consistent with his usual
views about scientific responsibility. We all make bad calls under such
circumstances (God knows *I* have). Please do not draw excessive conclusions
The key (verbatim) excerpt of our dicussion is the following:
>> [Jonathan wrote]
>> Also, would you agree at this point that our debate has shifted from
>> whether capabilities in principle can provide perfectly good security
>> (which you seem to have conceded) to a discussion of engineering and
>> performance tradeoffs? I agree (obviously, given my work of the last
>> decade) that these engineering issues are serious and need to be
>> addressed, and I'm interested in your views on this, but the first
>> step is to debunk the myth of infeasibility so that designers can then
>> have considered discussions about engineerability.
> [Dan replied]
>I'll concede that, if you extend your capability system in such a way to
>allow the kind of interposition we're talking about (i.e., not something
>supported by a traditional capability system), that you can potentially
>get the semantics that you want, assuming your type system allows you do
>this cleanly (Java's type system makes this very messy).
>If you're in a world where your method call overhead is something you
>measure in microseconds rather than clock cycles, then you've got a
>hope. If you're counting every clock tick, this kind of interposition
>will forever be impratical.
[End of excerpt]
I will append here to this exchange as follows. Most of this was said in
other words to Dan, but by repeating it here he has the opportunity to
respond publicly and selectively.
The key point above is that if you can successfully interpose, then you can
do policy. Contrary to what Dan says here, it is known that complete
interposition is feasible in pure capability systems. The KeySAFE system
demonstrated this, as did "Original E". Dan may think of such interposition
as creating an "extended capability system"; I think of it as an appropriate
use of pure capabilities. This is purely a terminology issue, and it is not
essential to the discussion.
I also disagree about the cost claim in the general case, though it's pretty
clear that the cost in a Java object system in particular is indeed
prohibitive (as Dan is saying).
The cost of such interposition depends on two factors:
1. How pervasively do you use it? Do you really need a protection boundary
for every object, or are compartments enough? In Java, regrettably, it must
be every object, because the interaction of per-object mutex and constant
string intern provides a channel guaranteed by the language specification
between any two objects, regardless of protection domain (curiously, C# has
replicated this design error faithfully). Some other issues in the Java type
system make things still worse.
The anecdotal experience with EROS suggests that this granularity of
protection is too fine, because programmers cannot in practice manage the
complexity involved in keeping track of such fine grain protection
2. Can you apply run-time optimization? Many of the costs in question can be
easily eliminated by (e.g.) the HotSpot runtime. I believe that these
techniques, correctly applied, will prove to contradict the "forever
impractical" claim, and in the absence of quantitative or explanatory
expansion, that statement must be taken purely as an assertion. Further,
they must be taken in context purely as an assertion about the Java
realization of capability security under the constraint of total backwards
That is, if you don't procede from Java compatibility as a requirement,
there is no quantitative evidence that the cost is prohibitive in general,
and some anecdotal evidence that it need not be. I hope someone will recall
and repost the overhead figures for EC's "Original E" here, in order to
provide another example.
Out of fairness to Dan, I should acknowledge that our private exchange
included some expansion on the "forever impractical" assertion in connection
with Java. As this is part of some ongoing work he is doing, and I am not in
a position to know which parts anticipate some forthcoming publication, I
will not include that excerpt here. I *will* say that the discussion used a
good example problem, but that the discussion seemed to consider only static
optimizations. Given dynamic optimizations, I believe that most of the cost
he says his team is seeing would disappear. Perhaps he will choose to expand
I apologize for being delphic on that last bit, but I really don't want to
accidentally scoop a work in progress. I would prefer that the "Original E"
team discuss here their experiences with the performance of pervasively used
object proxies. That would be relevant, and it might help Dan's group in the