Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Fri, 2006-05-19 at 11:23 +0200, Bas Wijnen wrote:
> The thing is that what our proposal (transparent space banks)
> makes impossible is for one user to give a space bank to an other user without
> the right to look at it himself.

Is the goal to make this impossible, or is the goal to empower the user
to make this impossible if they *choose* to do so?

For the sake of discussion, I would like to propose a variant scenario
for just a moment, so let me assume that we have a slightly different
design than the one proposed:

  There are opaque and translucent banks. The difference is that
  the opaque bank will not issue a given page more than once. A
  translucent bank will, which is how the user gains access to
  the content.

  An opaque bank can be a child of a translucent bank (or the
  other way around).

  There is a permission restriction on banks that prohibits formation
  of opaque sub-banks. If this bit is set, only translucent sub-banks
  can be allocated (this preserves recursive translucency).

  If an object is allocated from an opaque bank, it is marked (within
  the allocator) as opaque, and no parent bank will disclose it.

Let us, for just a moment, start from this design.

>From a purely technical perspective, it seems to me that there are two
parties, the user and the program, and each has a choice to make:

  The user can initiate the program from a translucent bank or
  an opaque bank.

  The program can check the type of its bank, and possibly decline
  to run.

Does this view violate the social objective that you are actually trying to
achieve?


In my opinion, users make choices about programs they will install. Some
are open, some are proprietary. Under GPL, we encourage them to use open
programs, but we do not prohibit them from using proprietary programs.
Unless I am missing something, the user's ability to insist on a
translucent bank allows them to refuse to run proprietary programs.

In the same way, vendors make choices: they choose not to deploy
programs on some platforms because they wish not to be open. Allowing
the program to insist on an opaque bank seems to model this.

Is the goal here to absolutely prohibit programs whose runtime memory
cannot be inspected by the storage provider, or is the goal to empower
the user to say "I will not run such 'closed' programs" (which can be
done with a single session configuration bit)?

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?


shap