Re: Part 2: System Structure

[Bas Wijnen]

On Mon, May 22, 2006 at 03:56:06PM +0200, Tom Bachmann wrote:
> Jonathan S. Shapiro wrote:
> >   The program can check the type of its bank, and possibly decline
> >   to run.
> 
> Just a minor detail, but I believe it cannot. Because if it runs on a
> transparent bank, the test could have been forged.

It can do this before actually running.  The system service which starts the
program (that service might be called a "constructor" ;-) ) is instructed to
do this check.  It will not start the program (and in particular, pass it
capabilities) if the memory is transparent.

> > The decision to enforce bank translucency is a technical means for
> > achieving a policy objective. I am trying to understand what the policy
> > objective is. Do we really intend to deprive the user of the choice to
> > accept DRM?
> 
> I personally believe we do not.

I think we do.  It depends on what your definition of DRM is, though, and on
what the price is.  It may turn out to be too high.  But in principle, making
DRM impossible on the system is a good idea IMO.

We should not give people the choice to be oppressed, because it is not the
people who choose this, but the oppressors (in this case by not providing any
non-DRM content).  If DRM is not possible on any system (if we would implement
it, it would be the only system where it's possible), they will provide the
content through other means.  Perhaps it's less content, but that's a
different discussion.  It's definitely more non-DRM content.

Let me be a little more clear:  The machine owner should be able to do
whatever she wants without going through too much trouble.  The user should be
able to do anything they are technically allowed to.  In particular, this
means:
- The space bank must not allow protection against the machine owner.
  Functions which require a reinstall or analysis from a different system are
  forms of protection.  (They can be circumvented, but at a considerable
  price.)  What I mean is that someone who holds a (full) capability to the
  primary space bank should be able to read and modify all memory in the
  system.
- If it turns out to be neccesary, the system may be set up such that users
  can give out memory that they themselves cannot modify.  Furthermore, it may
  be possible to give out memory that they cannot read.
- If a user receives a binary image of a not-installed program, she must be
  able to run it on transparent memory.  That is: the program must be unable
  to check if its memory is really transparent (a check may exist, but it must
  be forgable).  This must be possible without changing the binary image.

Now then, the question of transparency.  First of all I'm not entirely sure
what Marcus wants, but I'll say a few things about my opinion.

The default of running programs must be in a way that gives the user access to
their memory.  Almost all programs on the system must run like this.

I think it is a good idea if all space banks are recursively transparent.
This is to avoid protection against the machine owner, and doesn't limit
functionality in any way if a setup is chosen as I described in an earlier
e-mail, with special quota space banks used for quota and unlimited space
banks derived from them for actual programs and data.  It may cost
performance, though, but I think this cost will be minimal, especially if it
is optimised for this use pattern.  In fact, it may already be optimised for
it, because I suppose in most cases the quota will be set to "infinity" for
most space banks (which means the quota bank can be omitted).

As I wrote above, it may be needed to allow the user to give out read-only or
even no-access (to herself) spacebanks.  This should only happen in very
special cases.  It must not be possible without the user knowing that it
happens (allowing it for certain services through a config file constitutes
"knowing" in this case).

The transparent space bank doesn't make this impossible: If the session allows
this (and provides a means to check it), then the memory can easily be
unaccessable to the user (but not to the machine owner, if she chooses to keep
a capability to the primary space bank).

This means DRM is possible only if the machine owner allows it by installing
the stuff on the machine (if it's user-installed, it doesn't work) and if the
user explicitly agrees to use it.  It then still doesn't work against the
machine owner.  This probably results in the content providers considering it
"impossible" (because they cannot protect against the machine owner anyway).
That was exactly what we (well, at least I) wanted.

> I'd like to encourage everyone to consider this. It sounds like a viable
> compromise

What exactly is "this"?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature