Tue, 23 Nov 1999 14:37:20 -0800 (PST)
>> We don't define power to mean "secret", we define it to mean the right to
>> direct the action of some object. Secrets are merely a means of implementing
>> this idea.
>Your definition is still way too narrow. (By the way, you must mean
>the ABILITY not the right, or your arguments would not lead to your
>conclusions.) There are to many things people need to do (and can do),
>even in terms of computer security, were the notion of identity
Please explain what you mean by "too narrow". We've actually tried to make our
definition as narrow as we could, in order to limit our efforts to things which
can actually be implemented. But then, as Einstein said, things should be as
simple as possible but no simpler. If we have erred in this way we want to
You may be correct in saying I'm equating abilities and rights. In our network
model these are the same thing. There is obviously some additional quality you
attribute to rights (in contrast to abilities) that you think is important, but
I'm still unclear as to what it might be. Could you expand on this?
>Even a program has an identity. Verifying identity may be tricky, but
>it isn't impossible. Even "biometrics" can be used on programs. A
>cryptographic signature for the programs code is the digital
>equivalent of a fingerprint.
If the decision you are trying to make is whether to permit a piece of code to
execute in an environment under your control, this is correct. However, if you
are trying to make a decision as to whether to extend the same trust to what is
alleged to be this same code in a remote environment not under your control,
the signature is only useful for this purpose to the extent that you trust the
entity who *is* in control of that environment. It is the latter trust problem
that we are trying to manage here.
>> Given that what I stated is a non-existence claim, it is of course
>> impossible to prove, though it may be disproved by a counterexample.
>This isn't the Lock Ness Monster we're talking about here.
>Nonexistence proofs are the bread and butter of anything theoretical.
>Radical claims do not loose their substantial burden of proof just
>because they are stated in nonexistence terms.
Except in certain formal systems, non-existence proofs generally *are*
impossible, but I think your fundamental point is still correct. I don't think
we need to get into a long digression on epistemology, since I suspect we'd
mostly agree anyhow. I was simply stating that one good counterexample will be
more persuasive to me than any number of pages of closely reasoned argument.
>> Though you
>> say that finding counterexamples is easy, I haven't seen a counterexample yet.
>> I'd actually like to see a counterexample, because if you are right it gives us
>> a leverage point to do some other interesting things.
>I don't think I will ever come up with one for which you cannot say
>"Oh, that's outside the domain of discussion." Given your narrow
>definition of a power, and your assumption that the actors are
>abstract entities that interact only by sending messages, and maybe a
>few other assumptions I haven't noticed yet, your conclusions may
>actually be correct.
Within the limited confines of purely electronic relationships between
computational entities, I'm fairly certain I'm correct. However, the
interesting problems which prompt this discussion come up when we try to tie
things like capabilities and ERTP to things in the real world of human beings,
real estate, physical goods, and so on. So I'm extremely interested in
understanding where you think the concepts don't map well.
>Suppose before Alice gives Bob a power, she insists that bob let her
>examine his source code, and verifies that no information Bob receives
>from Mallet can ever affect Bob's use of the power. This example
>violates your other assumption (it only works for programs not for
>abstract entities), but it is not idle speculation. Consider how Java
>uses it's byte code verifier to enforce its security policies.
As I said above, unless Bob is running within an environment under Alice's
control, letting her examine Bob's source code doesn't do much for her since
regardless of what properties she may able to prove about the code, she still
has no way to verify that this is the code that Bob is actually running.