Re: Joins on capabilities that have passed through different membranes
<[email protected]> Tue, 5 Jan 2016 09:43:19 -0800
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAG7xX7ptLySxEQLjhFgBtOy_pro5fUQ_VNO8-14DgYNN_rMoeQ@mail.gmail.com> |
--===============8270003370360310553== Content-Type: multipart/alternative; boundary=001a113d2424f27e76052899c52a --001a113d2424f27e76052899c52a Content-Type: text/plain; charset=UTF-8 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 On Tue, Jan 5, 2016 at 9:38 AM, Alan Karp <[email protected]> wrote: > 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 > > 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 >> >> > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > > -- Ihab A.B. Awad, Palo Alto, CA --001a113d2424f27e76052899c52a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Cool -- to my mind, this is a plausible design solution.<d= iv><br></div><div>It requires that the individual caps provide some sort of= comparison operation -- and, preferably, that the user agent be aware of t= hose APIs and use them to amplify where needed. I <i>assume</i> this can be= presented non-confusingly to users, but it would be interesting to test th= at out.</div><div><br></div><div>As for merging -- with such an API in plac= e, the individual caps can now negotiate between each other to decide what = their "merge" should represent. Different domain objects may impl= ement "merge" in different ways. Again, one would have to come up= with a UX for that, and see if and how users understand it.</div><div><br>= </div><div>Does that make sense?=C2=A0<br><div><br></div><div>Ihab</div></d= iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, = Jan 5, 2016 at 9:38 AM, Alan Karp <span dir=3D"ltr"><<a href=3D"mailto:a= [email protected]" target=3D"_blank">[email protected]</a>></span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There are two issue= s in this example, which document and whether to amplify.=C2=A0 Ihab can kn= ow which document by making sure the capability he sends to Kenton has a me= thod that returns a value meaningful to Ihab, such as the document name.=C2= =A0 Deciding whether or not to make the change Kenton requests is a matter = of policy, not one of ambient authority.=C2=A0 Ihab uses the value returned= by Kenton's capability and the suggested change to decide whether to m= odify the document using Ihab's existing rw capability.=C2=A0 This deci= sion can be represented by an Edit button in the UI.=C2=A0 If Ihab doesn= 9;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.</div><div class=3D"gmail_extra"><br= clear=3D"all"><div><div><br>--------------<br>Alan Karp</div></div> <br><div class=3D"gmail_quote"><div><div class=3D"h5">On Tue, Jan 5, 2016 a= t 8:24 AM, <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>></span> wrote:<br></div></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div c= lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jan 5, 2016 at = 4:41 AM, David Bruant <span dir=3D"ltr"><<a href=3D"mailto:bruant.d@gmai= l.com" target=3D"_blank">[email protected]</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"><span><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can you provi= de a concrete example of why one would want to perform the join instead of = just using the two capabilities separately?<br></blockquote></span></blockq= uote><div><br></div><div>I'm going to take a guess. This is a problem w= e 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.</div><div><br></div><div>* Let's say I have a document I own a= nd have read/write access to. Let's call my capability to it [rwdoc].</= div><div><br></div><div>* I share a read-only cap to that document with Ken= ton. I say something like, "Hey Kenton, check out this stuff I wrote u= p at [rodoc]. Regards."</div><div><br></div><div>* Months later, Kento= n replies to me, saying, "Hey Ihab, I think you need to add the follow= ing information to [rodoc], because some new stuff came up! Kthxbai."<= /div><div><br></div><div>* The cap [rodoc] arrives in my user agent -- brow= ser or whatever. Now what? There is no simple "correct" solution.= </div><div><br></div><div>-> 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 situa= tion a bit more complex, with Kenton's original example, you end up wit= h the joining problem he has raised.</div><div><br></div><div>-> If my u= ser agent does nothing, then I have "two ways" to get to one logi= cal document, and we don't know how to explain this state of affairs to= end-users.</div><div><br></div><div>I think this is a UX research problem.= :)</div><span><font color=3D"#888888"><div><br></div><div>Ihab</div><div><= br></div><div>--=C2=A0<br></div></font></span></div><span><font color=3D"#8= 88888"><div>Ihab A.B. Awad, Palo Alto, CA</div> </font></span></div></div> <br></div></div><span class=3D"">__________________________________________= _____<br> cap-talk mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">cap-talk@mai= l.eros-os.org</a><br> <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"norefer= rer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a>= <br> <br></span></blockquote></div><br></div> <br>_______________________________________________<br> cap-talk mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><= br> <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"norefer= rer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a>= <br> <br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla= ss=3D"gmail_signature">Ihab A.B. Awad, Palo Alto, CA</div> </div> --001a113d2424f27e76052899c52a-- --===============8270003370360310553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk --===============8270003370360310553==--