Re: [friam] Re: UX resources for object capabilities

In the ocap systems I have been a part of building, the distinction between
user and administrator blurs almost completely out of existence. The
administrator is a user with great authority, and he creates users with
less authority; users with less authority can create a user with any amount
of authority up to the amount the creating user holds.

3 interesting examples for your audience:

http://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf

Is a tech report about using the ocap language Emily, built atop OCAML
using an ocap verifier, to build sash, a framework for writing
least-privilege bash commands. This is a small but complete example of a
powerbox and apps that are invoked with user-specified very limited
authority. The powerbox holds all the user's authority, the app gets only
what the user specifies, designated in a way that any unix bash user can
understand even though no acls are involved: the act of designation is the
act of authorization, so you're mainly doing what you'd do with bash
commands mainly different in that that bash commands are launched with vast
abusable power. This one may "sing" for your unix audience more easily than
the other 2, they can actually read the code.

https://www.youtube.com/watch?v=cJThfgXMBA4

Is a 2 minute video of the everyware desktop. So, the everyware desktop
runs in a browser, and manages authorities all over the blinkin' web. But
the principles are the same, and IMHO anyone who writes a new user desktop
in this day and age should not be fooling around with desktops that govern
only local authorities anyway. Anyway, the desktop in the demo is the
user's visual representation of his powerbox that holds all his authorities
over documents, chat threads, etc. This video shows an actual flow of
authority from user to user (desktop to desktop) in a simple secure
cooperation scenario. For people who think the distinction between
administrator and user is important, it might be interesting to note that
Homer is actually the root administrator for a full everyware system, and
Madge could be either an account holder on that system, who got her desktop
via a series of desktop sub-creations rooted in Homer, or could have her
desktop on a different everyware system, we neither know nor care, because
ocap authorities flow transparently user-to-user regardless of
administrative boundaries.

http://decideright2.com

Is the location where you can create an account for the DecideRight2
decision analysis application. Your home page -- reached via an ocap OAuth
bookmark --
is once again a visual representation of your powerbox, i.e., it contains
all your system authorities; in this case each authority is an ocap
reference to a decision analysis document. Each document enables grant of
limited authority to edit and/or read a single decision. While least
directly relevant to the unix OS problem, it has the merit that this one
you can actually operate live, to see how it all works.

--marcs

On Mon, Nov 2, 2015 at 8:09 PM, William ML Leslie <
[email protected]> wrote:

> "User driven access control: rethinking permission granting in modern
> operating systems (Oakland 2012)" is a great place to start.  From
> there, many of the cited papers are handy too.
>
> You can get the paper from __apf__'s list here:
>
>
> https://docs.google.com/document/d/1N5uTePbaHGGz70nX5zc28Cil026f80oR_ypAxo5ar40/edit
>
> --
> William Leslie
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> prior contractual agreement.
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk