Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Thu, 2006-05-18 at 01:45 +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 17/05/2006 hora 11:32:
> > All you want is totally possible with a transparent space bank.  The
> > only thing is that the one who wants to keep his program secret has to
> > pay for the storage.  Ok, and encapsulation isn't guaranteed to the
> > instantiator.
> 
> Do you think that the EROS Trusted Window System is really implementable
> with a transparent storage? I would think it is theoretically
> impossible...
> 
> And I'm not sure I want to give up the possibility of a such secure
> windowing system. I really think Marcus make an unbalanced decision
> here, by removing security to defend agressively user's freedom.

Actually, I don't think there is any negative impact on EWS. EWS is a
primordial service that runs from system storage. It runs in
mostly-constant storage (might change when you swap the video card) that
is allocated directly from the prime bank. The choice of bank might want
to change, but it definitely comes from a bank that is pretty far up the
hierarchy.

But this *does* suggest a use compelling use case:

There are a number of cases where a proprietary file format is only
disclosed under an NDA. If I sign the NDA, I can learn the format. After
I sign the NDA, I cannot disclose the format, but I am free to write
programs that will convert the file from the proprietary format to an
open format. The MS Office file formats were examples of this for many
years.

It seems pretty obvious that we would like to encourage people to move
to open formats. However, this program cannot be run unless the
developer can ensure that its storage is opaque.

Notice that this is not a privileged program in any way. It would not
make sense to turn this into a system-wide utility. We *definitely* want
this program to be confined (it should not give my files away), and we
probably want to run a distinct instance of this program for every
conversion.


shap