[cap-talk] Capabilities and Freedom vs. Safety

[Stiegler, Marc D]

> Of course there are many judgment calls in this, and this is 
> where we will disagree. Let me give three examples of the 
> types of things that I am thinking about:
> 
>   1. The password file is clearly sensitive, and should be 
> accessed only
>      through protected library routines designed to protect its
>      integrity.
> 
>      Limitation: the system design should not bind the raw 
> password file
>      into any file name space -- even if the passwords are encrypted.
> 
>      Positive consequence: integrity is assured.
> 
>      Negative consequence: you may need to migrate password files
>      differently.

I could quibble, but why would I do that? :-)

> 
>   2. The system-wide installation utility should be able to install
>      programs in such a way that (a) they are confined when run, but
>      (b) the user cannot inspect their code or data.
> 
>        [Aside: I do realize that this requires cryptographic methods
>         for binary distribution.]
> 
>      Limitation: this preserves the proprietary character of code and
>      data. It is a form of DRM.
> 
>      Positive consequence: certain license terms can be liberalized
>      if this is technically enforced.
> 
>      Negative consequence: much harder for you (the user) to reverse
>      engineer this code.

I'm sure this is the one the "freedom" people have heartburn over. The
real negative consequence is that it is so incredibly difficult to
migrate your software to a new box. My wife has hundreds of books she
bought in RocketBook (encrypted, DRM'd) format, when the box finally
fails (it is on its last legs) it will be the moral equivalent of having
a whole library burn down. Unacceptable. And on a person level: never
again.

Having said that, this is the sort of thing the marketplace can sort
out. Just because I am likely to refuse to buy hardware-locked software
does not mean it is not acceptable for some people for some
applications. As long as it is also possible to download and install
programs that are confined when run, and the user can inspect their code
and data :-)

> 
>   3. It should be possible for programs to prevent the user from
>      altering their state (code, data or capabilities) without
>      proceeding through some mediating interface controlled by the
>      program.
> 
>      Negative consequence: harder to cheat on that game software.
> 
>      Positive consequence: harder to inject Trojan horses

Controlled by the program, or controlled by the OS? I suppose controlled
by the program is still necessary if you are going to do the DRM in #2.
Again, the marketplace can sort it out. Though I am skeptical that this
is the right place in the system to stand to be trying to prevent Trojan
horse injection. Before getting wrapped up with this one, I'd be
inclined to see whether a basic CapDesk approach to building desktops
didn't make Trojan horse injection hard enough that it wasn't an issue
any more. In which case, the positive consequence is moot.

> 
> In each case (at least in my opinion) there is a limitation 
> imposed on the actions of the user, but either (a) there is 
> another way to satisfy legitemate uses (e.g. by using the 
> password library) or (b) there was no
> *legitimate* user use being denied, and benefit is achieved 
> by denying illegitimate use.
> 
> For each of these cases I can describe contrived 
> counter-arguments showing why the negative consequence is not 
> desirable under some unlikely circumstance.
> 
> On balance, in my opinion, examples (1,3) are clearly 
> improvements and should be done. Example (2) gets into a very 
> subjective discussion about DRM and intellectual property, 
> but I intend that Coyotos will support it.
> 
> > My defense of my box has to be something I can do without 
> depending on 
> > a system designer to modify what other people can do with 
> their boxes.
> 
> This is ridiculous. If I can engineer any substantial number 
> of boxes so that they cannot be used as zombies in DoS 
> attacks, it is clear that you benefit greatly. The question 
> is not whether this is technically desirable. The question is 
> whether it is feasible in the marketplace.

Well, we disagree about whether it is ridiculous :-) In a world where
you can rent a spambot for $3/month, "any substantial number" has to
number in the hundreds of millions to significantly diminish DOS
attacks. Tens of millions, which sounds like a substantial number, is
just not enough to make a difference. The obvious real solution -- also
not currently feasible in the marketplace, so who cares? -- is
application of agoric principles to the Internet public commons.

--marcs