[cap-talk] Capabilities and Freedom vs. Safety

[Jonathan S. Shapiro]

On Fri, 2007-07-20 at 10:17 -0700, Marc Stiegler wrote:
> The phrase "design limitations into our systems to prevent inadvertent
> or intentional abuse" is both where we agree and disagree...

I was careful to add: "where we know how to do so in a way that respects
legitimate uses".

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.

  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.

  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

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.

> I would be more sympathetic to the view that we are all our brothers'
> keepers, and that the USA needs to keep hit teams on standby for
> tracking down Romanian teenage cybercrackers (the eventual necessary
> logical deduction of the above philosophy),  if we in this community
> didn't already know how to do better than that :-)

I am not proposing that these should be the only concerns or the only
mechanisms. I am merely trying to establish that "ultimate local
freedom" is not my design goal.


shap