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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
