[cap-talk] Joins on capabilities that have passed through different membranes

[Kenton Varda]

Hi Mark and cap-talk,

I'm interested to know if you've thought about the following problem:

You want to perform a join on two capabilities A and B, which were obtained from Alice and Bob respectively. Semantically, the two capabilities point to the same object, in that the messages passed to either one are ultimately routed to the same place. However, the two capabilities have different conditions under which they become revoked, because the original creator of the capability wanted to maintain the ability to revoke Alice's and Bob's access independently. Therefore, capabilities A and B are not really pointing to the same object. So, what happens when you join them?

The naive answer seems to be "they can't be joined because they're not the same". However, this answer seems highly problematic in practice.

It seems to me that it is necessary to separate the notion of the endpoint object to which the capabilities point from the notion of restrictions/requirements added on top of them (where cap A has the requirement "Alice's access has not been revoked" and cap B has the requirement "Bob's access has not been revoked"). When joining two capabilities -- as long as the endpoint is the same, then the requirements must be "merged".

"Merging" requirements could either mean taking the intersection (the joined capability is revoked if either original capability is revoked) or the union (the joined capability is revoked if *both* inputs are revoked). Intuitively, intersection seems more intuitive, but it means that any one party to the join can subsequently cause an outage of the joined capability by revoking their own input, which seems problematic in practical use cases. E.g. in the escrow case, if Alice owes Bob money upon completion of a contract, Alice could disrupt the contract capability just before it becomes complete so that the escrow agent never pays out. I haven't thought of any serious problems with taking the union of the requirements instead. Alternatively, it could be up to the entity performing the join to specify intersection or union, but if one or the other is almost always correct I'd rather not expose this additional cognitive overhead to developers.

-Kenton

[Bill Frantz]

On 1/4/16 at 5:53 PM, ken...@sandstorm.io (Kenton Varda) wrote:

>I'm interested to know if you've thought about the following problem:

I see a number of possibilities here. Lets assume that Alice's
cap is A , Bob's is B, and the underling capability is C.

We can have A merge B, B merge A, or a separate merge utility M.
M can either be in cahoots with the Revoker front ends Ra and Rb
or not.

If R has the authority to look inside other instances of itself,
Ra can look at Rb and determine that the Ra' C is the same as
Rb's C and "Do the right thing"tm.

If M is in cahoots with Ra and Rb, it can perform the same magic.

If all are independent, there may be some varient of the Ask Bob
Protocol which applies, bringing C into the act.

I would say that if either A or B is revoked, then M should not
perform a merge. (I hope A or B are revoked enough that Ra and
Rb can't perform a merge either.)

The life span of the result of the merge D is interesting. If it
has the same authority as A or B, then either would do as the
result of the merge. If it has more authority, then A and B
represent something more than a revokable version of C.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz | Airline peanut bag: "Produced | Periwinkle
(408)356-8506 | in a facility that processes | 16345
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos,
CA 95032

_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

[Kenton Varda]

I've heard of the "Ask Bob Protocol" mentioned a few times in the context of capability equality, but I don't think I've ever heard exactly what it does / how it works. Is there a good reference doc? It seems hard to Google.

-Kenton

[Chip Morningstar]

Kenton Varda <ken...@sandstorm.io> wrote:

>I'm interested to know if you've thought about the following problem...

It's not obvious to me that this one has a correct answer. Rather, it seems to
me that what you want to happen varies depending on use case and intent. You
might want the semantics to be "This revocation takes effect regardless of
which path to the ultimate object the holder of the cap uses". You might want
it to be "as long as someone has some path to the object, then they still have
access to it". These feel like joins with AND vs. OR like behavior, but that
may be pushing analogies too far. It possible there are other combinations
that make sense. As Bill pointed out, to the degree that the various objects
involved have various kinds of under-the-hood relationships with each other,
all manner of behavior is plausible.

Chip

[Alan Karp]

The name "Ask Bob" comes from a paper by Moni Naor about sharing a secret without revealing it.  (I have a copy, but it's in a box in my closet.)  In his paper, Bob told Moni, his manager, about a problem with another employee.  Later, Carol (I forgot the real name.) told Moni that an employee had made the same complaint to her.  It would be fine for Moni and Carol to reveal the identity of the complainer if it was Bob both times but not otherwise.  Being computer scientists, they came up with 10(?) ways.  For example, Moni would make a flight reservation for Bob, and Carol would cancel one in the name of the employee who complained to her.  Moni was explaining these solutions at dinner, when his son asked, "Why didn't you just ask Bob?"  Moni did, and Bob said it was OK to tell Carol.

I used the son's solution for e-speak, which used path-based names.  You didn't know if two names received along different paths referred to the same object.  I didn't think it mattered, but some customers freaked out.  In the Ask Bob protocol you send a different nonce along each path and ask for it to be returned on the other one.  If you get both nonces back, you know the references are to the same object.  If you don't, either the aren't, or the object is lying to you.  To the best of my knowledge, it was never used.

--------------
Alan Karp

[Bill Frantz]

On 1/4/16 at 7:05 PM, ken...@sandstorm.io (Kenton Varda) wrote:

>I've heard of the "Ask Bob Protocol" mentioned a few times in the context
>of capability equality, but I don't think I've ever heard exactly what it
>does / how it works. Is there a good reference doc? It seems hard to Google.

This is really a question for Alan, CCed. Dean might also have
some useful input as he has always been able to remove the need
for capability equality from practical problems.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz | I like the farmers' market | Periwinkle
(408)356-8506 | because I can get fruits and | 16345
Englewood Ave
www.pwpconsult.com | vegetables without stickers. | Los Gatos,

[Alan Karp]

I don't think unification makes sense.  In fact, it might even lead to a confused deputy vulnerability.   

--------------
Alan Karp

[Matt Rice]

On Mon, Jan 4, 2016 at 8:29 PM, Alan Karp <alan...@gmail.com> wrote:
>
> (I have a copy, but it's in a box in my closet.)

I recall you having linked to this paper on list previously

http://www.wisdom.weizmann.ac.il/~naor/PAPERS/comp.ps

[Lorens Kockum]

On Mon, Jan 04, 2016 at 08:37:18PM -0800, Alan Karp wrote:
> I don't think unification makes sense.

IMHO unification would only make some sort of sense if the union
of the two capabilities should give the possibility to perform
an act than cannot be performed by either of the capabilities in
isolation: I can do this because BOTH Alice and Bob agree. That
would be some kind of escrow protocol, and would probably need
some kind of escrow object. If you don't have the need for both
Alice and Bob to agree, then you can do with only one, and if
you can, then you should, just because it's simpler. I could
imagine some kind of added weight given by Bob's agreement, but
either you need it, or you don't . . . or it's a post-action
audit trail.

Happy New Year!

[David Bruant]

Le 05/01/2016 02:53, Kenton Varda a écrit :
> Hi Mark and cap-talk,
>
> I'm interested to know if you've thought about the following problem:
>
> You want to perform a join on two capabilities A and B, which were
> obtained from Alice and Bob respectively.

Can you provide a concrete example of why one would want to perform the
join instead of just using the two capabilities separately?

If you obtained two capabilities from two different parties, it seems
non-intuitive (to me at least) to want to merge them. You obtained a
capability from Alice and can do some things with it, you obtained a
capability from Bob and can do some things, why trying to merge them
(especially if you do not have prior knowledge that they may point to
the same underlying object)?

(assuming the join makes sense in the rest of my response)

> Semantically, the two capabilities point to the same object, in that
> the messages passed to either one are ultimately routed to the same
> place. However, the two capabilities have different conditions under
> which they become revoked, because the original creator of the
> capability wanted to maintain the ability to revoke Alice's and Bob's
> access independently. Therefore, capabilities A and B are not really
> pointing to the same object. So, what happens when you join them?
>
> The naive answer seems to be "they can't be joined because they're not
> the same". However, this answer seems highly problematic in practice.
>
> It seems to me that it is necessary to separate the notion of the
> endpoint object to which the capabilities point from the notion of
> restrictions/requirements added on top of them (where cap A has the
> requirement "Alice's access has not been revoked" and cap B has the
> requirement "Bob's access has not been revoked"). When joining two
> capabilities -- as long as the endpoint is the same, then the
> requirements must be "merged".
>
> "Merging" requirements could either mean taking the intersection (the
> joined capability is revoked if either original capability is revoked)
> or the union (the joined capability is revoked if *both* inputs are
> revoked).

or anything in between as suggested by others.

In your message, you're refering to the revokation policy, but
attenuation is also something that wants to be merged when joining.

Without loss of generality, it looks like merging code needs to be added
to the mix.

In initial context:
```
var O = {...}; // original capability, "same original object"

var capPolicyForAlice = {...};
var capPolicyForBob = {...};

var A = makeCapForAlice(O, capPolicyForAlice);
var B = makeCapForBob(O, capPolicyForBob);

// send A to Alice
// send B to Bob
```

in your context:
```
var A; // capability for O received from Alice
var B; // capability for O received from Bob

var M = merge(A, B);
```

Without more information, merge can only perform an intersection or
union of capPolicyForAlice and capPolicyForBob (assuming there even
exists an "intesect" or "unite" function that does something sensible
with these objects?)

Still, the code as written above does not tell where the merge function
comes from. Let's assume it comes from the initial context (maybe
travelled through Alice or Bob?). But at least, I don't think there is a
reason to assume there exists a global (and generic) merge function.
So there might need to be code that decides how the merge should happen.
At first guess, I'd say a reducer function attached to each policy.

The code in the initial context would then look lik something like:
```
var O = {...}; // original capability, "same original object"

var capToPolicy = new WeakMap();

var capPolicyForAlice = {reduce(otherPolicy){
return combine(this, otherPolicy);
// combine can be intesect, union, or something else
}, ...};
var capPolicyForBob = {reduce(otherPolicy){
return combine(this, otherPolicy);
}, ...};

var A = makeCap(O, capPolicyForAlice);
capToPolicy.set(A, capPolicyForAlice);
var B = makeCap(O, capPolicyForBob);
capToPolicy.set(B, capPolicyForBob);

function merge(o1, o2){
var capPolicy1 = capToPolicy.get(o1);
var capPolicy2 = capToPolicy.get(o2);

if(!capPolicy1 || !capPolicy2)
throw new Error('no idea how to merge these')

var mergeCapPolicy = capPolicy1.reduce(capPolicy2); // this is
asymetric

return makeCap(O, mergeCapPolicy);
}


// send A to Alice
// send B to Bob
```

With this "architecture", it's possible to join two caps leading to the
same object (... maybe I should have made nested weakmaps with the cap
target as first key, but you get the point) by merging their
revokation/attenuation requirements with arbitrary flexibility, but it's
only possible if someone in the chain has access to the policies that
need to be merged.

The reduce functions are given access to other cap policies at merge
time. It worries me a bit, but at the same time, they do need these
policies to perform the merge so it doesn't seem like abusive authority.

David

[Raoul Duke]

(I naively think that knowing what the real final endpoint would be in terms of eg 'eq' is the rare case for OCaps, since in OOP generally ideally one should have refs to interfaces, and not know/care what is doing the implementation behind those interfaces, including proxies/wrappers/delegators.) "This call results in Alice doing Y" is different than "This call tells Alice to do Y".)

[ihab...@gmail.com]

On Tue, Jan 5, 2016 at 4:41 AM, David Bruant <brua...@gmail.com> wrote:

Can you provide a concrete example of why one would want to perform the join instead of just using the two capabilities separately?

I'm going to take a guess. This is a problem we talked about extensively during the early parts of the Caja project, and discussed with our security PMs. From what I recall, we did not have a good answer.

* Let's say I have a document I own and have read/write access to. Let's call my capability to it [rwdoc].

* I share a read-only cap to that document with Kenton. I say something like, "Hey Kenton, check out this stuff I wrote up at [rodoc]. Regards."

* Months later, Kenton replies to me, saying, "Hey Ihab, I think you need to add the following information to [rodoc], because some new stuff came up! Kthxbai."

* The cap [rodoc] arrives in my user agent -- browser or whatever. Now what? There is no simple "correct" solution.

-> If my user agent automatically amplifies it to [rwdoc], that means the agent has ambient authority. In fact, that's what happens with browsers and cookies today! And when you make the situation a bit more complex, with Kenton's original example, you end up with the joining problem he has raised.

-> If my user agent does nothing, then I have "two ways" to get to one logical document, and we don't know how to explain this state of affairs to end-users.

I think this is a UX research problem. :)

Ihab

-- 

Ihab A.B. Awad, Palo Alto, CA

[Alan Karp]

There are two issues in this example, which document and whether to amplify.  Ihab can know which document by making sure the capability he sends to Kenton has a method that returns a value meaningful to Ihab, such as the document name.  Deciding whether or not to make the change Kenton requests is a matter of policy, not one of ambient authority.  Ihab uses the value returned by Kenton's capability and the suggested change to decide whether to modify the document using Ihab's existing rw capability.  This decision can be represented by an Edit button in the UI.  If Ihab doesn't have a rw cap to the document, the button can be disabled, or Ihab can be asked to create a copy to be edited.

--------------
Alan Karp

[ihab...@gmail.com]

Cool -- to my mind, this is a plausible design solution.

It requires that the individual caps provide some sort of comparison operation -- and, preferably, that the user agent be aware of those APIs and use them to amplify where needed. I assume this can be presented non-confusingly to users, but it would be interesting to test that out.

As for merging -- with such an API in place, the individual caps can now negotiate between each other to decide what their "merge" should represent. Different domain objects may implement "merge" in different ways. Again, one would have to come up with a UX for that, and see if and how users understand it.

Does that make sense? 

Ihab

[Kenton Varda]

The "join" operation I'm referring to is the one provided by E.

http://erights.org/elib/equality/index.html

http://erights.org/elib/equality/after-both.html

It seems to be a fundamentally necessary tool for a few use cases. Mark describes the "grant matcher puzzle" as an example:

http://erights.org/elib/equality/grant-matcher/index.html

I'm not sure "Ask Bob" works for this use case: If I understand correctly, it could only tell you that Alice and Dana claim to agree on the identity of KEQD, but it does not protect against one of them performing a MITM after claiming agreement. Once the Grant Matcher determines that they agree, it still has to send the money somewhere. Without a "joined" capability, it must instead send it to one of the two capabilities provided by Alice and Dana. Whichever one it chooses, the person who provided that capability can potentially steal the money using a MITM.

Ihab brings up a more common use case, which is actually already implemented in Sandstorm: Human users generally don't understand the concept of having multiple capabilities to the same document, possibly with different permissions. Human users also generally aren't anywhere near as susceptible to confused deputy attacks as everyone else. Therefore, as a convenience, when a human user receives two capabilities to the same document, we automatically join them. This join definitely takes union semantics, for obvious reasons. Note that in this use case, we are unioning not just revocation conditions, but also permissions/attenuations (e.g. read, write).

But I was more thinking about the grant matcher type of use case here. Or, rather, I'm trying to determine if there is any use case for join where intersection semantics are preferred rather than union.

I'm not too worried about implementation details at this point. I'm primarily trying to figure out what semantics are correct. A possible answer could be "union is always correct" and another could be "the caller needs to decide".

-Kenton

On Tue, Jan 5, 2016 at 8:24 AM, <ihab...@gmail.com> wrote:

[Raoul Duke]

> Dana. Whichever one it chooses, the person who provided that capability can
> potentially steal the money using a MITM.

The money should require 2 things in order to become really
transferred, with 1 sent on each channel :-)

[Alan Karp]

On Tue, Jan 5, 2016 at 10:19 AM, Kenton Varda <ken...@sandstorm.io> wrote:

I'm not sure "Ask Bob" works for this use case: If I understand correctly, it could only tell you that Alice and Dana claim to agree on the identity of KEQD, but it does not protect against one of them performing a MITM after claiming agreement. 

Correct, for exactly the reason you give. 

Ihab brings up a more common use case, which is actually already implemented in Sandstorm: Human users generally don't understand the concept of having multiple capabilities to the same document, possibly with different permissions. Human users also generally aren't anywhere near as susceptible to confused deputy attacks as everyone else. Therefore, as a convenience, when a human user receives two capabilities to the same document, we automatically join them. This join definitely takes union semantics, for obvious reasons. Note that in this use case, we are unioning not just revocation conditions, but also permissions/attenuations (e.g. read, write).

I'm not so sure that users aren't susceptible to confused deputy attacks without some additional context.  In SCoopFS, Kenton would have to send a message to Ihab saying, "Please make this change on my behalf."  That message would not include Kenton's capability; it just refers to the document by name.  Ihab must explicitly select his rw capability to make the change.  As I understand what you do in Sandstorm, Kenton uses his capability to make the request, which gets merged with Ihab's.  At this point, it appears to Ihab that he is making the change using Kenton's capability even though he's using permissions from his own.

Marc Stiegler came up with a clever UI affordance to make all this clear.  If Ihab views the document with Kenton's capability, Ihab sees a ro view.  If Ihab opens it with his own, he sees a rw view.  In either case, he see the same document, which reduces any possible confusion.  Since Ihab does have write permission, his UI has an Edit button (actually a tab in Stiegler's UI).

The same views are used for sharing, WYSIWYS (What You See Is What You Share).  If you click the Share button while in the Edit view, you share rw.  If you click in the Browse view, you share ro.  We need to do more experiments to see how easy that is for people to understand, but at least there's a concise explanation.

--------------
Alan Karp

--------------
Alan Karp

[Mike Stay]

On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <alan...@gmail.com> wrote:
> Marc Stiegler came up with a clever UI affordance to make all this clear.
> If Ihab views the document with Kenton's capability, Ihab sees a ro view.
> If Ihab opens it with his own, he sees a rw view. In either case, he see
> the same document, which reduces any possible confusion. Since Ihab does
> have write permission, his UI has an Edit button (actually a tab in
> Stiegler's UI).

Google's UI researchers claimed to us that people would get a
read-only view from somewhere and then be confused when they couldn't
edit it, even when there was an edit button. People don't look for
controls they don't expect to need.
--
Mike Stay
st...@google.com

[Raoul Duke]

Why should there be an edit button at all? If I go to try to edit it,
then it could tell me that I cannot, and offer instructions (even a
button, should that somehow be possible) that helps me get started on
getting over into edit mode.

[Kenton Varda]

On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <alan...@gmail.com> wrote:

I'm not so sure that users aren't susceptible to confused deputy attacks without some additional context.  In SCoopFS, Kenton would have to send a message to Ihab saying, "Please make this change on my behalf."  That message would not include Kenton's capability; it just refers to the document by name.  Ihab must explicitly select his rw capability to make the change.  As I understand what you do in Sandstorm, Kenton uses his capability to make the request, which gets merged with Ihab's.  At this point, it appears to Ihab that he is making the change using Kenton's capability even though he's using permissions from his own.

Yes, but Ihab is not a computer. He can look at the document and understand what the document is and what effect my requested change will have. He can decide if this change seem suspicious. Moreover if I ask him to make a change that I obviously could have made myself, he's going to wonder why I asked him to do it, and probably catch on to the fact that I don't actually have said permission after all.

This isn't foolproof, obviously. Social engineering is a thing. But social engineering could also work against SCoopFS based on titles, as you describe. Humans are relatively unlikely to be fooled just because I sent them a thing that looks like a capability, especially if they aren't capability-based security experts. :)

Humans, meanwhile, are much worse at managing multiple capabilities to the same object than computers are. So in the interest of UX, we make a compromise by auto-joining capabilities when they land in a human's capability store.

Marc Stiegler came up with a clever UI affordance to make all this clear.  If Ihab views the document with Kenton's capability, Ihab sees a ro view.  If Ihab opens it with his own, he sees a rw view.  In either case, he see the same document, which reduces any possible confusion.  Since Ihab does have write permission, his UI has an Edit button (actually a tab in Stiegler's UI).

I really doubt that a user would understand that landing on the read-only view implies that the sender only had read access, if an edit button or tab is readily visible and is normally part of the UI. The user would merely think: "Huh, why am I on the read-only view? I'll switch to edit mode so I can make the requested edit."

 

The same views are used for sharing, WYSIWYS (What You See Is What You Share).  If you click the Share button while in the Edit view, you share rw.  If you click in the Browse view, you share ro.  We need to do more experiments to see how easy that is for people to understand, but at least there's a concise explanation.

I see what you're going for here but my intuition is that users wouldn't get it, and that this UX doesn't scale well with complexity. Consider what happens when you add a "can comment" permission. Do we now have three tabs: "read-only", "read+comment", and "edit"?

I agree that it's useful for the sharer to be able to see exactly what they are sharing, but probably this needs to be accomplished via a UI that is explicitly offering to simulate the document with different permissions. Facebook offers something like this to view your own profile from the perspective of another user, for example.

-Kenton

[Alan Karp]

On Tue, Jan 5, 2016 at 11:46 AM, Mike Stay <st...@google.com> wrote:

Google's UI researchers claimed to us that people would get a
read-only view from somewhere and then be confused when they couldn't
edit it, even when there was an edit button.  People don't look for
controls they don't expect to need.

I think they are too pessimistic.  You can set up things so that a Word document is read-only when opened from an email attachment.  The header says it's read only, and you get the option to save a copy when you try to edit.  There's a momentary jolt when you try to edit, but I bet few people are confused for very long.

--------------

Alan Karp 

[Alan Karp]

On Tue, Jan 5, 2016 at 12:00 PM, Raoul Duke <rao...@gmail.com> wrote:

Why should there be an edit button at all? If I go to try to edit it,
then it could tell me that I cannot, and offer instructions (even a
button, should that somehow be possible) that helps me get started on
getting over into edit mode.

 

I believe Marc did that for consistency and as a cue for what other permissions you could ask for.

--------------
Alan Karp

[Alan Karp]

On Tue, Jan 5, 2016 at 12:01 PM, Kenton Varda <ken...@sandstorm.io> wrote:

On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <alan...@gmail.com> wrote:

I'm not so sure that users aren't susceptible to confused deputy attacks without some additional context.  In SCoopFS, Kenton would have to send a message to Ihab saying, "Please make this change on my behalf."  That message would not include Kenton's capability; it just refers to the document by name.  Ihab must explicitly select his rw capability to make the change.  As I understand what you do in Sandstorm, Kenton uses his capability to make the request, which gets merged with Ihab's.  At this point, it appears to Ihab that he is making the change using Kenton's capability even though he's using permissions from his own.

Yes, but Ihab is not a computer. He can look at the document and understand what the document is and what effect my requested change will have. He can decide if this change seem suspicious. Moreover if I ask him to make a change that I obviously could have made myself, he's going to wonder why I asked him to do it, and probably catch on to the fact that I don't actually have said permission after all.

I'm more concerned that Ihab will pass the merged capability as an argument to some function, perhaps by inserting it into a field in the UI 

 

This isn't foolproof, obviously. Social engineering is a thing. But social engineering could also work against SCoopFS based on titles, as you describe. Humans are relatively unlikely to be fooled just because I sent them a thing that looks like a capability, especially if they aren't capability-based security experts. :)

Humans, meanwhile, are much worse at managing multiple capabilities to the same object than computers are. So in the interest of UX, we make a compromise by auto-joining capabilities when they land in a human's capability store.

I think Marc Stiegler might disagree.  He's using this pattern in DecideRight2.

 

Marc Stiegler came up with a clever UI affordance to make all this clear.  If Ihab views the document with Kenton's capability, Ihab sees a ro view.  If Ihab opens it with his own, he sees a rw view.  In either case, he see the same document, which reduces any possible confusion.  Since Ihab does have write permission, his UI has an Edit button (actually a tab in Stiegler's UI).

I really doubt that a user would understand that landing on the read-only view implies that the sender only had read access, if an edit button or tab is readily visible and is normally part of the UI. The user would merely think: "Huh, why am I on the read-only view? I'll switch to edit mode so I can make the requested edit." 

Yes, but if instead of editing he clicks the Share button to send the document as an argument to a program, he'll be using Kenton's permissions, as he should.

 

The same views are used for sharing, WYSIWYS (What You See Is What You Share).  If you click the Share button while in the Edit view, you share rw.  If you click in the Browse view, you share ro.  We need to do more experiments to see how easy that is for people to understand, but at least there's a concise explanation.

I see what you're going for here but my intuition is that users wouldn't get it, and that this UX doesn't scale well with complexity. Consider what happens when you add a "can comment" permission. Do we now have three tabs: "read-only", "read+comment", and "edit"?

I agree that it can get complicated really fast, but it seems to work for a small set of permissions on the object.  Unfortunately, doing user studies at HP was virtually impossible, so we're not sure.  Clearly, we need something different for more than a few permissions.

--------------
Alan Karp

[Bill Frantz]

Many Mac applications put documents into read-only mode after a
number of days of no changes. When you try to change them, they
pop up a dialog asking if you want a r/w version. It really
isn't confusing.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz | Re: Computer reliability, performance, and security:
408-356-8506 | The guy who *is* wearing a parachute is
*not* the
www.pwpconsult.com | first to reach the ground. - Terence Kelly

[Matt Rice]

I'm not sure its something normal users would want to work with, but
Personally, I think it'd be nice to view the current applications capabilities
in the context of my directory structure...

Mac OSX has a 'proxy icon', thing, from the setRepresentedFilename:
method on a window, that can be dragged around to various
applications...

http://stackoverflow.com/questions/21101562/how-to-have-multiple-proxy-icons-in-cocoa-document-windows

I'd prefer something where similar but where click on the proxy icon,
sends the windows capabilties to something like the shelf in:

http://debian.uni-duisburg-essen.de/misc/GNUstep/Docs/SystemOverview/pictures/workspace.png

I could then select the thing on the shelf to view it within the
context of what is labeled the viewing area (where presumably i would
have a RW capability sitting nearby)..

The shelf, was typically used both as a place to put commonly used
things, and as a scratch space for temporary usage, I think this usage
requires to keep those two functions separate by some means,

so a shelf area for the capabilities from the window, and a shelf area
for commonly used stuff, this commonly used area would also see usage
as a scratch area when I want to do something with the capabilities
from more than one window...

worth considering what I recall has been said is that keykos had some
fairly long lived capabilities, is it presumed that the [rodoc]
received is the most recent and synchronized whenever I edit [rwdoc],
or some ancient version where a newer one may already has the
requested change...
I think its worthwhile to be able to do a reality check, before just editing...
I'm not sure it isn't even applicable in those cases we can generally
assume a synchronized copy could exist in writer -> editor -> publish
scenerios, you generally want to speak about a very specific version
of a capability when it comes time publish.

On Tue, Jan 5, 2016 at 8:24 AM, <ihab...@gmail.com> wrote:
>

[Marc Stiegler]

"Humans, meanwhile, are much worse at managing multiple capabilities to the same object than computers are. So in the interest of UX, we make a compromise by auto-joining capabilities when they land in a human's capability store."

So, I keep on pressing people to think of capabilities as being like documents, and managing them as documents, which is very simple and easy to do with webkeys that are dragged and dropped onto the desktop from the browser and auto-converted into shortcut docs.

Consider the following example: Carol is working with Alice on project A, and with Bob on project B. Both project A and B involve using document D. So:

Carol has all her project A docs in folder ProjA, and her project B docs in folder projB.

Alice sends Carol a webkey for D. Carol drops it into folder projA. When working on A, Carol clicks the webkey in projA.

Bob sends Carol a webkey for D. Carol drops it into folder projB. When working on B, Carol clicks the webkey in projB.

It never makes a difference to Carol whether the cap for A and the cap for B are pointing at the same document or not: they might be pointing at variations of D that are intended to be merged another day, Carol does not care! She uses the correct cap in the correct context, and it just works right.

Humanity solved the problem of managing caps when Xerox invented the desktop metaphor for document organization, because we already have the facility to make caps behave as docs. We just have to recognize that this problem is solved, and use the solution.

--marcs

[Matt Rice]

I think the thing i was trying to get at, is that this "drag and
dropped onto the desktop" action that Carol initiates to escape Bob
and Alice's authority,
and interpret Bob and Alice's capabilities within Carols authority

Mainly because I don't think its as simple as which authority on
bob/alices capabilities to invoke, but which of Carol's authorities to
invoke on which of Carol's capabilities, and subsequently where the
result belongs, I don't think its a decision anyone but Carol can
make.

[Kevin Reid]

On Jan 4, 2016, at 17:53, Kenton Varda <ken...@sandstorm.io> wrote:

> Hi Mark and cap-talk,
>
> I'm interested to know if you've thought about the following problem:
>

> You want to perform a join on two capabilities A and B, which were obtained from Alice and Bob respectively. Semantically, the two capabilities point to the same object, in that the messages passed to either one are ultimately routed to the same place. However, the two capabilities have different conditions under which they become revoked, because the original creator of the capability wanted to maintain the ability to revoke Alice's and Bob's access independently. Therefore, capabilities A and B are not really pointing to the same object. So, what happens when you join them?

As has been mentioned already, the party performing the join is making itself potentially have a confused deputy problem because it now has a capability with more authority than any given purpose-for-which-it-was-given.

However, that's its own problem, and in the case where ‘it’ is a person, which I assume is your case, we know people are fairly good at dealing with it.

> The naive answer seems to be "they can't be joined because they're not the same". However, this answer seems highly problematic in practice.

This naïve answer is correct under the case where Alice and Bob separately constructed membranes/caretakers that don't know about each other, _and_ you don't want to construct a joined capability yourself. But there's no technical reason against the latter: you construct a capability whose behavior is to forward to one or the other of the two.

The only global feature required to do this is to be able to ask “are these two caps the same modulo revocation?” -- THAT is what you need to think carefully about the existence and semantics of.

> It seems to me that it is necessary to separate the notion of the endpoint object to which the capabilities point from the notion of restrictions/requirements added on top of them (where cap A has the requirement "Alice's access has not been revoked" and cap B has the requirement "Bob's access has not been revoked"). When joining two capabilities -- as long as the endpoint is the same, then the requirements must be "merged".

-- and I think this is my previous paragraph in different words.

> "Merging" requirements could either mean taking the intersection (the joined capability is revoked if either original capability is revoked) or the union (the joined capability is revoked if *both* inputs are revoked). Intuitively, intersection seems more intuitive, but it means that any one party to the join can subsequently cause an outage of the joined capability by revoking their own input, which seems problematic in practical use cases.

As far as I can see, your intuition is being unhelpful. What reason to do an intersection is there?

(Well, I can see it as a part of establishing some policy, for example, deliberately giving both Alice and Bob the authority to revoke. But I think it would be better to express that policy in a fully explicit way which is not a “join”.)

One way to think about a unionis as a matter of reliability: you have two “communication paths” and you try whichever one works. (Or send an idempotent message on both.)

> Alternatively, it could be up to the entity performing the join to specify intersection or union, but if one or the other is almost always correct I'd rather not expose this additional cognitive overhead to developers.

I hope you are not proposing to, at the programming level, _implicitly_ perform a join. This would be harmful DWIM. I see no reason not to _implement_ a union and not bother to implement other options -- unless you are building a non-extensible system which would then be unable to express an intersection.

--
Kevin Reid <http://switchb.org/kpreid/>

[rmeijer]

On 2016-01-05 21:01, Kenton Varda wrote:
> On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <alan...@gmail.com>
> wrote:
>> Marc Stiegler came up with a clever UI affordance to make all this
>> clear. If Ihab views the document with Kenton's capability, Ihab
>> sees a ro view. If Ihab opens it with his own, he sees a rw view.
>> In either case, he see the same document, which reduces any possible
>> confusion. Since Ihab does have write permission, his UI has an
>> Edit button (actually a tab in Stiegler's UI).
>
> I really doubt that a user would understand that landing on the
> read-only view implies that the sender only had read access, if an
> edit button or tab is readily visible and is normally part of the UI.
> The user would merely think: "Huh, why am I on the read-only view?
> I'll switch to edit mode so I can make the requested edit."
>

Perfect, you could offer a drop down right there so the user is asked to
designate the cap:

Document is currently opened with read only privileges as supplied by
Bob.
Re-opening the document in rw mode requires the use of authority
obtained
from other sources. please pick the source of authority you want to
use:

|Carol |V| |Edit|
|Dave |
|Eileen |

[Sandro Magi]

I'm skeptical of this UI claim. This behaviour is exactly what happens
when people open Word attachments directly from some e-mail clients. An
additional strip at the top says you're in read-only mode, and provides
a button to begin editing. This pattern has clearly existed for many
years already, and persists to this day, so it can't be so confusing as
to be unusable.

Sandro

On 05/01/2016 2:46 PM, Mike Stay wrote:
> On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <alan...@gmail.com> wrote:
>> Marc Stiegler came up with a clever UI affordance to make all this clear.
>> If Ihab views the document with Kenton's capability, Ihab sees a ro view.
>> If Ihab opens it with his own, he sees a rw view. In either case, he see
>> the same document, which reduces any possible confusion. Since Ihab does
>> have write permission, his UI has an Edit button (actually a tab in
>> Stiegler's UI).
> Google's UI researchers claimed to us that people would get a
> read-only view from somewhere and then be confused when they couldn't
> edit it, even when there was an edit button. People don't look for
> controls they don't expect to need.

[John Lee]

Presumably Google have more data than Microsoft on the usability of their
prototypes (how widely used is Office 365 now? does it work this way?).
Maybe that's the reason they stopped there and failed to see the
alternatives that do work?

Of course I don't mean to say that measurement in UI research isn't useful
-- just that it is easy to be overconfident of what is being measured, and
to put too little emphasis on guesses about how people think. It sounds
like they made a good guess, but didn't follow through with that, perhaps
because a traditional response to this sort of test is to throw away the
experiment and move on to the next feature. I suspect the bigger the
dataset, the more tempting this is ("how could we be wrong? we measured
ten million users").


John

[Mike Stay]

I have issues with their claim as well; in particular, I don't think they ever tried making it a coherent caps-based system, but tried to use some caps-like ideas in their existing system.

--

Mike Stay
st...@google.com

[Kenton Varda]

I don't think "If people understand email attachments they can understand caps" is a good argument.

Email attachments have significantly higher cognitive overhead than Google Docs does today. Yes, a lot of people get it, but at a mental cost, and some people (probably, people that people like us rarely interact with) could never handle it at all. Google Docs is widely considered to be a huge improvement over that world. If we're going to tell people that we want to go back to an email attachments paradigm, then we need a damned good reason.

And IMO, there really isn't a good reason. If we're going to argue that humans are susceptible to confused deputy, we need examples, but I've never heard of one. (This is in stark contrast to computers, where we have an endless list of examples.)

If we fight battles where we don't have strong evidence to back our case, people will stop taking us seriously.

So, I choose to concede this one.

With that said, if someone did come up with real evidence that confused deputy is a problem for humans, it would not be hard to adjust Sandstorm to work differently. Our model is primarily capability-based under the hood, with automatic merging built on top as a feature.

-Kenton

[Sandro Magi]

On 20/01/2016 12:14 AM, Kenton Varda wrote:

I don't think "If people understand email attachments they can understand caps" is a good argument.

No one made this argument. The argument made was specifically about the usability of the UI pattern of opening a document in read-only mode because it was opened with another person's authority. The fact that this pattern has existed for over 10 years and few have clamoured for this default to change should be evidence that it's usable enough, contrary to the original claim that it would be confusing.

Email attachments have significantly higher cognitive overhead than Google Docs does today. Yes, a lot of people get it, but at a mental cost, and some people (probably, people that people like us rarely interact with) could never handle it at all. Google Docs is widely considered to be a huge improvement over that world.

If Google Docs truly had *significantly* lower cognitive overhead, then everyone would be using it, and there would be plenty of clones of it competing for this influx of users. I've seen no such evidence. Microsoft has its own online office suite, but still boasts brisk sales of offline Office software.

Having personally used Google docs many times, I will merely say that it has advantages and disadvantages, but that local office suites and e-mail isn't going anywhere anytime soon. It's still the default at every one of my clients, in fact.

I have no real opinion on the viability of capability merge, but I will say that users misuse their authority on behalf of others all the time. I've dealt with many situations in which they mistakenly gave customers discounts they shouldn't have, approved purchases beyond what they reasonably should have, and plenty more. And these weren't uncommon either, to the extent that clients wanted mandatory controls to prevent most such mistakes.

I would not be surprised at all if users were susceptible to confused deputies, but I certainly think it's a worthy experiment because of the potential usability benefits.

Sandro