http://blog.gmane.org/gmane.comp.capabilities.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.capabilities.general/14094 <pre>but no promise to do penance. I've been involved in a discussion with folks about a coming NIST standard on policy expression. Once piece of their document explains how they decide whether or not to honor a request, which turns out to be via ambient authorities. I pointed out that they've got a confused deputy vulnerability, to which they responded, "The interpretation given seems correct. Therefore, this problem might exist." Unfortunately, that's all they had to say on the matter. Oh well, I guess that's progress of a sort. ________________________ Alan Karp Principal Scientist Enterprise Services, Office of the CTO Hewlett-Packard Company 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp </pre> Karp, Alan H 2013-05-23T15:00:23 http://comments.gmane.org/gmane.comp.capabilities.general/14093 <pre>https://workflowy.com/ Allows users to create a tree of "to-do" items. Each sub-item, at any level of the tree, can be shared by publishing a URL to a read-only or editable (selectable) to the item. Ihab </pre> ihab.awad-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2013-05-23T02:29:58 http://comments.gmane.org/gmane.comp.capabilities.general/14059 <pre>This may fall into the category of stating something obvious that everybody else but me already knew, but: I had a thought as I was rereading The Ode To The Granovetter Diagram in the course of preparing a presentation I'm going to be giving. In the capability paradigm, the standard list of ways one object can end up with a reference to another object is typically articulated as 1) by parenthood, 2) by endowment/construction, and 3) by introduction. I think MarkM's thesis also ads 4) by initial conditions. We typically diagram this stuff using unidirectional message patterns, and so we model the usual programming language call-return pattern in the continuation passing style, where the return is explicitly handled as a second message sent to an addressee who was passed as a parameter in the first message that corresponds to the call. Our standard rhetoric about the logic of introduction starts with Alice holding references to Bob and Carol and passing the Carol reference to Bob in a message, with the rep</pre> Chip Morningstar 2013-05-07T23:32:42 http://comments.gmane.org/gmane.comp.capabilities.general/14056 <pre>For the last few days, I have been receiving double copies of every list post. Anyone have any idea what’s going on? _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> John R. Strohm 2013-05-04T22:05:21 http://comments.gmane.org/gmane.comp.capabilities.general/14040 <pre>I was wondering if anyone had thought about the similarities and differences between CapNProto &lt;http://kentonv.github.io/capnproto/&gt; and CapIDL &lt;http://www.coyotos.org/docs/build/capidl.html&gt;? Both the goals and the means seem to have many similarities. The clearest difference seems to be that CapNProto is optimized for network communication whereas CapIDL is optimized for IPC. But, since CapNProto has kept compression well modularized as a mostly separate concern.... The next difference is that CapIDL was designed for synchronous IPC, where the type of value that the callee returns is the type of value that the caller's marshalling wrapper returns. CapNProto OTOH will be doing net communication with promise pipelining, and so will need to generate promise-lifted type wrappers. In a statically typed context, the best open precedent for that AFAIK is Waterken. Regarding the protocol itself, CapNProto values efficiency more highly than computability with existing web protocol notions (which are inherently te</pre> Mark Miller 2013-04-30T04:14:33 http://comments.gmane.org/gmane.comp.capabilities.general/14037 <pre>http://spectrum.ieee.org/computing/networks/bitcoin-hits-1billion/?utm_source=techalert&amp;utm_medium=email&amp;utm_campaign=040413 ________________________ Alan Karp Principal Scientist Enterprise Services, Office of the CTO Hewlett-Packard Company 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp </pre> Karp, Alan H 2013-04-04T21:02:16 http://comments.gmane.org/gmane.comp.capabilities.general/14036 <pre> how much traction is this expected to get? in certain domains? general purpose? what will the slam dunk demo be of it? etc. while i love better abstractions, it seems like hardware is the worst place on earth in terms of competition, uptake, compatibility, etc. to try to fight against the main stream. :-( </pre> Raoul Duke 2013-04-04T16:18:58 http://comments.gmane.org/gmane.comp.capabilities.general/14025 <pre>Anybody doing capabilites work on Google's Go? ________________________ Alan Karp Principal Scientist Virus Safe Computing Initiative Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp </pre> Karp, Alan H 2013-03-28T15:46:03 http://comments.gmane.org/gmane.comp.capabilities.general/14016 <pre>Some 10 years ago HP removed all vestiges of e-speak from its web sites. I've been trying to locate copies of them since 2005 to no avail. A search of the Internet Archive didn't turn anything up, but I just found the URL for one of the pages. Putting it into the Wayback Machine worked! Anyone interested in the SPKI version of the product can find lots of information on it at http://web.archive.org/web/20001019061924/http://www.e-speak.hp.com/. There is some basic information on the Client Utility version at http://web.archive.org/web/20000312172347/http://www.e-speak.hp.com/index.htm, and the documentation is at http://web.archive.org/web/20000816083124/http://www.e-speak.net/library/library_white.html. I'm sending this note to cap-talk as much as a way to remember these links as to inform other of them. ________________________ Alan Karp Principal Scientist Virus Safe Computing Initiative Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 htt</pre> Karp, Alan H 2013-03-27T18:03:53 http://comments.gmane.org/gmane.comp.capabilities.general/14009 <pre>Cap-talk, For anybody who might have missed it (as i had): http://spectrum.ieee.org/computing/embedded-systems/cisco-ip-phones-vulnerable Seemingly a vulnerability that's been around for quite some time. --Jed </pre> Jed Donnelley 2013-03-13T07:03:56 http://comments.gmane.org/gmane.comp.capabilities.general/14000 <pre>Rob Harper has provided a compelling argument for considering exception handling as conveying authority to communicate between two parties: http://existentialtype.wordpress.com/2012/12/03/exceptions-are-shared-secrets/ He doesn't phrase it exactly as above, but considering how long the E folks have been trumpeting that exceptions leak authority, it's just another example of how security analysis and type analysis often walk the same path. Sandro </pre> Sandro Magi 2013-03-12T02:34:16 http://comments.gmane.org/gmane.comp.capabilities.general/13999 <pre>Hi, The "ACLs don't" paper [1] describes a clickjacking attack where a malicious website tricks the user into clicking in an iframe triggering an action on a different website. We've seen that with some websites were using that to trick users into clicking a Facebook "like" button so that the user "likes" a page it might not have "liked" otherwise. The attack relies on the "like" iframe being at a public (same for all users) URL, clicks to the button send an HTTP request carrying with a cookie conveying (sometimes misleadingly) a "like" intent back to Facebook. A solution to prevent this attack is for Facebook to make "like" iframe URLs non-public. However, suddenly, the deployment story of such a system and I think the usability seem to suffer. Currently, websites just need to add an iframe with a URL containing some identifier their relevant Facebook page. Users just need one click on any supporting website to express their "like" intent. How would a capability-based system look like so that </pre> David Bruant 2013-03-11T13:25:18 http://comments.gmane.org/gmane.comp.capabilities.general/13992 <pre>Identity of site deleted to protect the guilty. It's like the old joke. "If you can't read this sign, ask at the next gas station." ________________________ Alan Karp Principal Scientist Virus Safe Computing Initiative Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp </pre> Karp, Alan H 2013-02-11T17:56:21 http://comments.gmane.org/gmane.comp.capabilities.general/13988 <pre>Cap-talk, I thought folks might find this paper interesting: http://fish2.com/ipmi/itrain.html --Jed </pre> Jed Donnelley 2013-02-01T18:56:32 http://comments.gmane.org/gmane.comp.capabilities.general/13987 <pre>I know many people on this list have a pretty strong dislike for memory insecure languages, so I hesitated a bit before posting this out of fear of starting an other C++ bashing flame. I wrote a little blog post about a simple C++ construct that I had been using for a while that uses a capability-like construct for delegating the ability to invoke the constructor of resource claiming classes: http://minorfs.wordpress.com/2013/01/18/raiicap-pattern-injected-singleton-alternative-for-c/ The base concept is that any resource claiming class requires a class specific RaiiCap reference, and only the programs 'main' can create such RaiiCaps (and delegate them to specific sub-systems). I would be very much interested if in other (memory safe) languages like Java or C# that do come with classes and constructors but that don't come with a 'friend' keywords or templates, a similar construct could be possible. </pre> Rob Meijer 2013-01-25T07:27:11 http://comments.gmane.org/gmane.comp.capabilities.general/13986 <pre>I'd like some help encoding the HERON access policy as a smart contract: "For qualified faculty who want view-only access to do patient count queries, executing a system access agreement is the only requirement. A Data Request Oversight Committee (DROC) oversees requests to ... sponsor collaborators and research team members." In particular, the workflow goes like this: 1. A faculty member uses one page to build a list of people to sponsor, then hits "done choosing people"; the list of people goes into a sponsorship request form, where the faculty member adds a title/description and supporting documentation, and submits the request. 2. Notice goes to all members of the Data Request Oversight Committee (DROC). The DROC consists of representatives of the 3 participating institutions (kumed.com, kumc.edu, and kuphysicians.com; don't ask) with a pointer to a form to review the request. 3. Once representatives of all three organizations agree, either to approve or reject the request, notice goes to the fa</pre> Dan Connolly 2013-01-19T00:00:48 http://comments.gmane.org/gmane.comp.capabilities.general/13974 <pre>At http://code.google.com/p/es-lab/downloads/detail?name=distr-erights-in-js.pdf Paper for invited talk at ESOP2013 http://www.etaps.org/2013/esop13 Final already submitted, but comments of course appreciated anyway. Distributed Electronic Rights in JavaScript Mark S. Miller Tom Van Cutsem Bill Tulloh Contracts enable mutually suspicious parties to cooperate safely through the exchange of rights. Smart contracts are programs whose behavior enforces the terms of the contract. This paper shows how such contracts can be specified elegantly and executed safely, given an appropriate distributed, secure, persistent, and ubiquitous computational fabric. JavaScript provides the ubiquity but must be significantly extended to deal with the other aspects. The first part of this paper is a progress report on our efforts to turn JavaScript into this fabric. To demonstrate the suitability of this design, we describe an escrow exchange contract implemented in 42 lines of JavaScript code. -- Cheers, --MarkM</pre> Mark S. Miller 2013-01-14T22:45:33 http://comments.gmane.org/gmane.comp.capabilities.general/13949 <pre> stuff with entities that don't need it. POLA is not the only valid principle in secure design. For example, see Ka-Ping Yee's ten principles of secure interaction design [1]. The principles of *revocability* and *visibility* are also relevant in the expression of parent-child relationships - i.e. you cannot grant an authority that you cannot later take back, and you can always see what authorities you've granted. Or put another way, to the extent possible security decisions should not depend on foresight and should not be fully committed, so support hindsight and takebacks. [1] http://www.andrewpatrick.ca/CHI2003/HCISEC/hcisec-workshop-yee.pdf The fact that you "see nothing special" seems to be a consequence of wearing POLA blinders. Last e-mail you even jumped from "from a POLA point of view" to "so basically in my view ideally", as though POLA is the only view you attempt and the only and ideal you have. That really bothered me. I think it is not a wise place to be, mentally. In practice, the develop</pre> David Barbour 2013-01-10T17:21:09 http://comments.gmane.org/gmane.comp.capabilities.general/13922 <pre>On Monday, the machines serving cap-talk and other mailing lists are being relocated. Email sent to the list between 9am PST and 2pm PST will be delayed. If you get a "still trying" notice during this period, please ignore it. _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Jonathan S. Shapiro 2013-01-06T04:53:52 http://comments.gmane.org/gmane.comp.capabilities.general/13918 <pre>Here's a new topic for discussion: Has anyone done a formal analysis of bitcoin -- the communications, not the software -- in terms of capability theory? For review, the bitcoin chain is a public record of all bitcoin transactions, ever. I'm thinking out loud here, please correct, extend, or ignore :) Block chain extension operations: When a participating node finds a good-enough solution to a hard problem, it gets to write a block to the chain. And doing so describes the next hard problem. In capability language, could one say that the good-enough solution constitutes a capability to extend the block chain? Account operations: Bitcoin secret keys are used to create many incoming-transaction capabilities -- they aren't revocable, but they can't be arbitrarily invented without the secret. And when someone gives BTC to a BTC address, that is done by revoking a previous incoming transaction and creating multiple new transactions? So a bitcoin transaction can be considered a capability -- the capability fo</pre> David Nicol 2013-01-01T00:02:25 http://comments.gmane.org/gmane.comp.capabilities.general/13893 <pre>In the past I had great hopes for the 'foundation' AppArmor/MinorFs/E-Language that I believed to form a very awesome stack to base least authority systems on. AppArmor is a security framework available for Ubuntu and Suse that allows one to specify 'initial' static privileges to executables, lets say the static part of POLA regarding programs/processes and their access to the file-system. MinorFs adds the dynamic part of POLA to the mix for file-system access and provides the glue needed to make file-system access fit with E's persistent VATs. E finaly takes POLA way beyond just file-system access. After completing MinorFs I gave this talk quite some times and got enthusiastic feedback, so I had hopes people would start using the AppArmor/MinorFs/E-Language stack. http://minorfs.wordpress.com/2011/05/25/taming-mutable-state-for-file-systems/ But when contacting several people at organisations where I gave my talk, those that remembered my talk stated they never actually ended up with a project suitable, </pre> Rob Meijer 2012-12-19T06:56:45 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.capabilities.general