[cap-talk] Another "core" principle

[Rob J Meijer]

> I didn't say it is OK to prevent people from doing their work.  What I
> did say is that current systems have very destructive, non-recoverable
> operations, and people have learned to live with them.
>
> It is desirable to have an undo for most operations.  With some membrane
> implementations, it is possible to turn the switch back on after
> communications have been stopped.  Whether just turning things back on
> would be effective depends on whether the objects affected can recover
> when their access comes back.
>
> Another approach would be to have a way of asking, "If I zap this
> membrane/space-bank/disk, what will no longer function?"  Only one of
> the problems here is giving the user an answer she can understand.
>

We are talking incident response here I believe.  As I hope Rick Tucker
and me showed in our (not caps centered) "State-full risk assessment &
automated security incident policy enforcement" paper, the
'technical' user  can not be expected to posses sufficient knowledge about
the financial impact of incident response actions even if he possesses
sufficient technical knowledge about 'what will no longer function'.
The paper was written without delegation in mind, thus some conclusions
might need some adjustments in the light of cap systems, but I feel most
of it should hold valid for delegation through proxy patterns.

Instead of focusing on getting the user to understand what will no
longer function, the burden of this knowledge and implications should be
positioned in the iterations of system design and risk analysis.
Risk analysis should show essential revocation points that should be
implemented in the next system design iteration in such a way to implement
'proportional response', and should further result in a policy for the
user that she must adhere to in case of specific incidents.
If the user can understand the technical impact is irrelevant given that
the user can not ever be expected to understand the combination of
technical impact, financial impact and risk escalation or mitigation posed
by a particular revocation or re-delegation/un-revocation action.
The user needs to be handed a clear policy on incident response and does
normally not need to understand its implications.

I feel the focus on trivial uncomplicated Alice/Bob/Carrol example
scenario's is distracting from the fact that revocation is essentially
an IR action, and that proportional IR relies on risk analysis that in
'realistic' scenario's requires such an amount of stochastic analysis
that it is not realistic to assume that any Alice could actually figure
this all out by herself within a time frame that does not by itself
escalate the risk in question.

Rob

Rob