[cap-talk] Reducing the authority of a file browser in a capability OS.

[Rob Meijer]

On Wed, December 23, 2009 06:33, David-Sarah Hopwood wrote:
> Rob Meijer wrote:
>> On Wed, December 23, 2009 00:03, David-Sarah Hopwood wrote:
>>> Rob Meijer wrote:
>>>> If the system has some way to restart the instance that created the
>>>> file (a pseudo persistent process), than this instance would have
>>>> persistent access to the files it created.
>>>
>>> Why should it? If we're just talking about document files, then that's
>>> excess authority.
>>
>> The alternative seems to be placing the unattenuated file into the
>> global
>> namespace prematurely without the user's explicit request to do so,
>> cluttering up the namespace that this user needs to administer.
>
> The file gets put into the user's namespace when the user saves it under
> a particular name. If the user closes the app instance, they get a prompt
> to save the file and if they cancel that, the file is discarded. I don't
> see a problem here; it works just as users would expect from existing
> operating systems, except that there is isolation between app instances.

Yes, it works as the user has come to expect from using a global namespace
as one and only solution for years. Does this justify not adhering to the
principle of least authority and the principle of least knowledge? I'm not
sure. From a practical point of view it might.
What you are doing however when stating that:
  "If we're just talking about document files, then that's excess authority."

What is stating that the private namespace solution (where files saved by
the persistent process initially end up in the private filesystem
namespace of the persistent process) constitutes excess authority.

My view is that this is actually inverse. Placing it prematurely (without
any indication of an intend to share) in a common namespace constitutes
the excess authority, while the private namespace solution constitutes
least authority. Going for least authority in this case might indeed
conflict with going for maximum familiarity, but this is quite a different
issue.

>> For me the ideal user interface would allow
>> me
>> to ask one pseudo persistent process for an icon representing a
>> revocable
>> capability that could than be drag-dropped to a second process OR pseudo
>> persistent process without the intervention of a file chooser type
>> powerbox at each end forcing the user to use and clutter this global
>> namespace that the powerbox is made responsible of.
>
> Drag and drop is a separate issue. The file doesn't need to be in a global
> namespace in order to be dragged-and-dropped; why would it?

Drag and drop isn't quite a different issue when you think about what you
are actually doing with the shared namespace. You are "prematurely"
putting rw capabilities into this shared namespace in order to later allow
the user to attenuate and delegate these capabilities from this namespace
to other program instances. My view is that:

* In a true least authority system there should not be a shared namespace
  for files and directories.

Instead drag&drop should provide an alternative by allowing the user
(shell/powerbox) to delegate capabilities that the application chooses to
expose to the shell/powerbox. In such a system the powerbox would look
like something of a drag&drop patch panel rather than the backward
compatible and maximum familiarity solution of a file chooser.

Having said this, I have tried several times to come up with a proto type
for such a drag&drop patch panel powerbox that would work with MinorFs,
but untill now have not succeeded in creating one that is both simple
enough and complete enough. I remain convinced however that someone with
better HI design skils than myself should be able to produce a descent
graphical representation for a drag&drop patch panel powerbox. Given such
a graphical drag&drop based interface, the resulting powerbox solution
would require much less authority, and would not require the cluttered
hard to administer common namespace to work.


Rob