[cap-talk] Drag & "Attenuated" Drop?

[Rob Meijer]

On Thu, September 3, 2009 22:29, Raoul Duke wrote:
>> Any time the user has to make security decisions, he
>> will not understand, will not want to, will not change
>> his focus of attention away from the task at hand to the
>> security implications of the task at hand.  So we have
>> to piggy back permission on designation.
>
> i fear most users will not understand the full implications are of
> their designations.
>

Thats why the 'default' full implications should I think be the minimally
intended implications. That is a default drag&drop of a directory should
ideally delegate a deep read-only attenuation that get the same lifetime
as the actual process that it is delegated to, and thus gets auto revoked
ones the receiving process ends.

But with the default being the minimal, the question remains how do we
allow the user to, with minimal strain or effort, to express their intent
for wider implications of their drag&drop action.

Given that the example of drag-dropping a file is a small and simple
subset of that of drag&drop-ing a directory, lets look at what authority
potentially could additionally gets delegated by the user, and lets look
at what other revocation patterns may be relevant for the user.

A delegated directory attenuation actually consists of a tree graph with 3
distinct types of nodes, each with their own possible attenuated
permissions:

1) The top directory node actually being delegated.
   a) List directory content
   b) Delete file from directory
   c) Create new file in directory
   d) Create new sub directory
2) Directory nodes at other levels in the tree graph.
   e) List directory content
   f) Delete file from directory
   g) Create new file in sub directory
   h) Create new sub directory in sub directory
3) File leaf nodes.
   i) Read file.
   j) Modify existing file.

If we assume that a+e+i is the minimal and default set to delegate on
drag&drop, there are still 7 more that the user might or might not want to
additionally delegate by taking some additional action.
Presenting the user with full-control as I proposed earlier might be
to much for an average user to handle. I feel it is important to look
at what useful bundles the user may want to delegate and at how to
represent these bundles in a work-process relevant way.

Both the unattenuated (a+b+c+d+e+f+g+h+i+j) and the deep ro attenuation
(a+e+i) are the simple cases. What other bundles are usefull and
representable in a work-process relevant way I'm not sure of.

Next to the initial delegation, we have the issue of revoking that is
potentially an even harder issue to tackle. If the default revoke
everything on process end is used, it is quite simple and needs no user
interaction.  My initial idea would be to define a single name space for
non auto revoked delegations, and have the user define a petname for the
delegation when not wanting the delegation to be auto revoked.
Alternatively a 'delegations' namespace may be bound to the delegated
dir, but I'm not sure yet if this would actually be better than having the
user supply a petname.

As with delegation, the fine control will also not likely be useful to
most users, so again, revocation will need to work with meaningful
bundles.

Rob