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

[David-Sarah Hopwood]

Rob Meijer wrote:
> 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,
>>> 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?

It does adhere to those principles. First of all, there is no global
namespace. When I said "the user's namespace" above, I meant the one
that is granted by the user to the powerbox accessible to that app
(which is likely be shared with the powerboxes accessible to some
other apps, but not necessarily all of them). It's quite likely that
the namespace accessible to most such powerboxes would not include
system configuration files, for instance.

Namespaces are first-class, and each namespace has whatever scope the
user wants it to have:
 - they can create browsers that only have access to particular namespaces;
 - they can attenuate namespaces;
 - they can delegate parts of namespaces to other users, or link part
   of one namespace into another;
 - they can choose to only log in with credentials that give them access
   to a particular set of initial namespaces.

A given browser (including a powerbox dialog, which is a special case
of a browser), does have browse access to a namespace, but it does
not have read or write access to the files in that namespace.
It obviously needs browse access; that is part of its least authority.

A small amount of code -- I estimated 30 lines -- has r/w access to
(potentially) all of a user's files. I don't see the problem with this.
The filesystem implementation, which we have to trust with r/w access
to all files anyway, is much larger than that.

> 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.

It does, because if I'm understanding correctly, an application will be
able to retain access to all of the files it created. In my approach it
can't do that: when a user explicitly closes an application instance,
the app's direct access to the current file opened in that instance is gone.
It will only be granted again if the user chooses to do so.

> My view is that this is actually inverse. Placing it prematurely (without
> any indication of an intent to share) in a common namespace constitutes
> the excess authority,

The user indicated an intent to place the file in a namespace by saving it.
Whether the namespace is common (shared) depends on how the powerbox of
the app was instantiated, but I would expect it to be shared in most
cases, and I think that's absolutely fine.

> while the private namespace solution constitutes least authority.

The private namespace approach assumes that files belong to particular
apps. That is not the case; files have a format, and can potentially be
used by *any* app that (directly, or indirectly via a converter)
understands that format.

If you force users to organise files in namespaces associated with the
apps that created them, that's a step backwards from the model we have
now, where users can choose the organisation of their files subject only
to the limitations of a hierarchical directory structure. It may be that
we can improve on a hierarchical directory structure, but that needs to
be a separate project to supporting capability security for the existing
model.

> Going for least authority in this case might indeed conflict with going
> for maximum familiarity, but this is quite a different issue.

The issue isn't just familiarity; it's flexibility. Organising files
only by their creating app is too restrictive and inflexible.

>>> 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.

Drag and drop has nothing to do with namespaces, shared or otherwise.
The source window gets a drag event, and responds with an icon and a
promise for the dragged object. The destination window gets a drop event,
which gives it the promise. (Perhaps there is some format negotiation,
but that doesn't change anything fundamental.) No namespaces -- at least
not in the sense of directory namespaces -- need be involved; just plain
event handling, implemented in terms of message passing with anonymous
objects.

> 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.

Drag and drop cannot provide an alternative to shared namespaces. Some
users don't like drag and drop at all (it certainly has significant
usability and accessibility problems), and avoid using it.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091223/3a56aec9/attachment.bin