> what about something like an IDE where you want to open many files?
I can't call myself a capability programmer, but I can take a stab at that:
First, and this sounds glib, but it isn't: one has to decide what the program needs, and arrange that users can grant it that, but not more (of course this is an ideal not a reached endpoint, but I don't want to apologize for an under-applied principle). This is the principle of least authority. Programs, and objects, can't operate without the authority they need. According to cap adherents, most of the work in designing and implementing more-secure systems should be in the detailed working out of what is needed and how objects and programs talk to each other, passing authority to and fro in the process.
To apply the powerbox UI pattern and similar patterns, it isn't necessary for there to be a literal dialog, and in fact a good place to start is: 'what is the UI now, if I were to remove all UI associated with "security"'? So for vim, why not :e? A goal could be to drop the parts where you have to run sudo and type in your password (or maybe there are parts of vim where vim prompts for your password so vim can do that for you, using the resulting ambient authority). Powerbox-like principles have been applied to the command line (e.g. plash; there are more recent systems). That is UI too.
UI patterns, access granularity (e.g. your example: directory cap or file cap?) and access control patterns have to match the problems you want to solve in all their product-/domain-specific detail, like any other part of software engineering. So, if say all you are concerned with is constraining read access on the file level, "opening many files" one at a time and then subsequently "switching between files", there is nothing more to do, and "granting directory access" is not necessary (though it wouldn't imply creeping ambient authority, just coarser-grained access). Only the powerbox needs access to the directory. If you're writing an IDE, there will of course be parts of the IDE that deal with directories. The task of applying object capabilities pervasively to systems like that involves going a long way past the powerbox, and expressing in language-level objects what each part of the system needs and how it obtains and passes on that access (with dramatically lower friction than we commonly have easy access to today). The task of getting the software industry to the the point where that is commonplace involves creative shortcuts that are both useful and feasible, like Google Caja and SES, sandstorm, plash, capdesk, etc (Caja and SES is unusual in advancing both these tasks). How to do that well starting with existing IDEs is a project for an inspired person, not an HN comment, but I sketched some ways below :-)
If it's necessary to provide only temporary access, use patterns like membrane.
While "omit the 'security UI" is a good place to start, Mark Miller (Google Caja, ECMAScript committee, etc.) has said that software security took a wrong turn some time around 1960 (I may be out by a decade or so). If you take that seriously, you should expect that capability security is behind in finding UI patterns that are well-optimized to a parallel world in which obj cap UI and the infrastructure that supports it has been hammered on by creative people for 60 years. ACL UI has been through that process of enormous effort and talent applied to this world in which almost everything is done using ACL security. So, if one wants to find the truth of whether obj caps can provide objectively better UI and security, I'd say the only way to answer those questions is to invent the answers, and see how they hold up. Of course it's made more of a challenge by the need to find the right small steps, and not rewrite all software! But there are plenty of projects that have shown that's possible technically. If you want a path where you don't have to invent new stuff just to stay afloat: of course don't use capabilities.
You may well appreciate this already, but there's an irony to hearing "windows store apps already work this way" (same for iPhone I believe: that's what I was referring to) when for the longest time, a few people knew how to solve the problem, even that was not implemented in real systems. We still don't apply the same lessons in most of software engineering. In fact, I don't know if most of the people who applied it to those mobile systems even knew that what they were doing is called capability security. For me the lesson to take from mobile phone use of powerbox-style UI is that capability-style security patterns work, and that if we applied it, knowing that's what we're up to, I bet that there is much more progress to be had in that direction.
How would you change vim to support just :e-as-powerbox, in a not-yet-cap-friendly world? That's a challenge! Maybe you'd take a heavy, sandboxing approach that tries to cut out the work to make vim use capabilities internally. So perhaps process-level sandbox gvim, pull out the ex line handling into a library, and dynamically link an unsandboxed process that provides an X window that replaces the ex line. Obviously there would be plenty of things to work out there! Similar things have been done before however: e.g. I recall plash also supported sandboxing firefox with a powerbox injected dynamically via LD_PRELOAD (with limited isolation: sandboxing has moved on since then) -- but I would expect vim to be hard. But on past history I am probably missing a trick.
Perhaps more ambitious (I'm not sure), but much more powerful and scalable, maybe you'd choose to start with spacemacs instead of vim, and design an object-capability subset of elisp that still leaves it feasible to port enough elisp to get the project off the ground. Workable obj cap subsets like this, that can interoperate with old code, have been done for other languages (notably JavaScript).
> What happens when I want to install an a different file browser that needs global read/write abilities?
How would you swap out file browsers? In general a good answer is dependency injection. More detail would be getting into detailed software engineering and very specific choices, not to mention the current software landscape (again, the LD_PRELOAD hack is an example). I don't think there is anything intrinsically harder about that with caps than non-cap techniques: in fact the opposite, because capability discipline requires good separation of concerns, and therefore at least encourages dependency injection.
Global read/write abilities? Not sure I follow what you are thinking: A plain-old powerbox typically has global read/write abilities (or only read, if that's what you want). The objects or programs that use the powerbox do not, because they have no means to do so except through the user granting that, using the powerbox. Of course a particular cap system might restrict that further if that was appropriate in the domain.
> How does that work with something like an IDE? You have to pass the compiler a bunch of files names and you'd have to pass the access permission with them, then compiler has to create a new executable with the ability to run and pass the access back to the IDE. And that's just for the simple case. For that matter, how does it work with command line tools that pipe file names between them?
It isn't necessary for compilers to use file names to get access to files, and in fact that's a clear violation of capability discipline: it involves ambient authority. In fact this very example with compilers and file paths happens to be historically the original example of a general situation that causes a whole category of bugs that can be prevented by use of capabilities: see the "confused deputy problem", and the wikipedia entry on ambient authority. For command lines, take a look at plash (or more recent related efforts if that's not on the web any more... if you can't find them, reply and I'll dig). Or just consider this simple example from plain old shell, sans capabilities (from David Wagner):
$ cp foo.txt bar.txt # cp must run with all of the user's authority
$ cat bar.txt # cat needs no authority other than what's given to it
(this doesn't imply that compilers need be ignorant of file names, by the way)