Re: Joins on capabilities that have passed through different membranes

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,  <[email protected]> wrote:
>
> On Tue, Jan 5, 2016 at 4:41 AM, David Bruant <[email protected]> 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
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>