11 ms·

What prevents capability based security models from widespread adoption? Is it again the fault of UNIX being “not bad enough”?

urbit 9y ago
This is a great question. One possible answer: maybe the right system would use "ambient authority" (ACLs, etc) for the common case, but scale up to true capabilities for interesting corner cases. Creating capability UIs that compete, in the common case, with the normal ambient-authority design, is ferociously hard. This seems to be where most capability systems falter. The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Think about all the places you can type a filename or a URL. If the designator and the authorization have to travel together, and the pair is an unforgeable capability, then user-entered designators (like paths or URLs) are not practical. Designators can't travel through unsecured paths, through the human mind, etc. This is a painful limitation. That said, the OP is the best explanation of capabilities I've ever seen. Everyone really should read it.
- kentonv 9y ago
  > The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Heh, I'm not sure I'd describe Sandstorm as "leading" anything right now, but thanks. :) I think Sandstorm made the problem more difficult for itself by not just trying to solve this UI problem, but trying to do it in a way that can be integrated into existing codebases that were never designed with capabilities in mind. This is the really difficult part: dealing with legacy code. The powerbox itself is otherwise "just a picker", a fairly straightforward concept. For example, the standard file-open dialog box in everyone's browser, when invoked from an upload button on a web site, is actually a powerbox: the web site itself is given no access to any files except the one that the user chooses, but the file-open dialog is able to see everything. But imagine trying to graft this approach onto an existing native app, that is used to being able to read the hard drive directly and already has its own custom file picker UI built in. You have to convince the developers of that app to remove their nice custom UI and instead invoke the system's UI. Moreover, when they invoke the file picker, they now don't get back a file name, but rather an already-open file descriptor. So their code has to be adjusted to not expect a name. This could be hard, depending on how the code is organized: maybe it uses a bunch of libraries that expect to open a file by name, etc. Sandstorm is trying to graft this model onto apps that are used to making HTTP API requests to each other directly. We had designs figured out to make this work, and even make most of the process look like an OAuth request, so that existing OAuth-based apps might not need to change very much... some of this is implemented, but mostly we just didn't get there before running out of money. (I am still working on it in my spare time, though!)
  - urbit 9y ago
    Protip: if no one's ahead of you, you're leading :-) This is a great answer. I think the impedance-mismatch question is a big part of the problem. Personally I prefer to boil the ocean rather than drowning in the impedance-mismatch tarpit. Both of these strategies are, of course, profoundly insane. It's true that a file-open dialog box easily becomes a powerbox. But of course, you are using the ambient authority of the user's login session to ascribe authority to the path that gets typed. So in a way it's the exception that proves the rule. And does a URL bar easily become a powerbox? What about a command-line shell? Perhaps we're both just agreeing that there is always trivial ambient authority, and the right way to scale up to nontrivial cases is a capability model. I just worry that when too many people discover the beautiful screwdriver that is capabilities, they decide that everything should be a screw. But the world has nails. It may even be true that the world should have nails. And then you find yourself pounding in nails with the butt of your screwdriver. Have you considered an ICO? Asking for a friend :-)
    - kentonv 9y ago
      I agree that capability people tend to get too extreme, and this tends to lead to failure. With Sandstorm we've tried to be more pragmatic, but still careful not to do anything that breaks the whole model in the long run. Whether or not the URL bar of a browser is a kind of powerbox depends on how extreme you want to get. In a pure capability model, yes, it would have to be. And hypertext would no longer be plain data -- it would be data with embedded capabilities (for each link), and would have to be transmitted via a protocol that can track capabilities. Obviously that kind of stuff, even though it would be amazingly powerful in a lot of ways, is not practical. :/ > Have you considered an ICO? Asking for a friend :-) People keep asking me that, often citing Urbit as an example to follow. :) At the moment I'm having too much fun at my day job building Cloudflare Workers (an unusually practical project by my standards!), and want to focus my outside-of-work time on coding Sandstorm rather than fundraising for it. In the future, who knows.
      - urbit 9y ago
        If I can distill my objection to the pure capability model: there are two different statements of the capability manifesto, one strong and one weak. The weak capability position is that it should be possible to construct an opaque combination of designator and authority, ie, a capability. The strong capability position is that designator and authority must always follow the same path. So in the "pure capability model," you are actually subtracting a feature from the system. Now, of course, it's often the case that subtracting a feature makes a system better. But one needs to be really clear about confusing this with the positive virtues of just having capabilities. Also, while I agree that capabilities are really great (Arvo has a somewhat capability-like internal communication model), it's important to point out that (a) capability vs. identity is a duality; and (b) it's cheating to compare a good capability system to a bad identity system. For (a), note that identity systems can implement capability features like delegation and revocation; they just have to do it actively rather than passively. If I am willing to act as your deputy, I can delegate my power to act to you. Or some restricted subset thereof. Tell me what to do and I'll do it. For (b), if you put a decent capability system next to the Internet, a network whose identity model is a burning-tire dumpster fire. If your identity system actually works and makes sense, competing is harder for the capability design. I do think Urbit should have some kind of capability model. However, this has the feel of a 2.0 or even 3.0 feature. I hate to solve a problem until it is actually in my way. I feel we have come nowhere near the limits of the common case. A simple map from identity to privilege is certainly that. And while capability UIs may be doable, identity UIs are trivial. This would not be the first case of humans being funky, hence screwing up our elegant architectural logic. If you have a system software project and it can advance without being lashed to a company, definitely do it that way! It's always a poor fit -- they have to succeed on different timelines. One thing I know: once we all have personal servers, today's cloud will look pretty lame in retrospect...
- EtDybNuvCu 9y ago
  Unforgeability can be weakened systematically to unguessability: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v... Unfortunately, the concept of "taming", where ambient-authority systems are used to implement functionality in capability-safe systems, is often a sad and frustrating path due to massive impedance mismatch. Like you say, paths are not caps, which means that capability-safe languages on UNIX-like systems are constantly dancing to tame the OS. As usual, it would be great if you made your VM cap-aware, so that we may eventually get over this hump.
  - abecedarius 9y ago
    It's worth noting that WebAssembly should go nicely with capability systems. Mark S. Miller started a thread on the mailing lists recently about making sure it stays that way.
kentonv 9y ago
My opinion, as the designer of Sandstorm, a capability-based server OS: Capabilities are not the way developers are used to thinking. It may be that if people got used to it, it would make sense -- or it may be that it's simply too complicated and most developers will never wrap their heads around it. I honestly don't really know which it is. In this respect, it feels a lot like functional programming (FP and capabilities are very different concepts, but are similar in that it takes a while to fully understand how to use them effectively). We do see capability systems appearing by accident all over the place. Unix file descriptors, for example, behave very much like capabilities. Once open() finishes successfully, all access checks are done -- they aren't repeated for every read() or write(). You now have a capability, and you can even send that capability to other processes (even running under different UIDs that wouldn't have permission to open the file directly) via Unix domain sockets. People who really get how to exchange file descriptors build some amazing systems with them (without ever realizing they're building capability systems). But, for some reason, most systems do not really try to take advantage of FD passing, and instead opt to do things like listen on a globally-accessible port and perform an authentication handshake on incoming connections. I guess this kind of design just seems more obvious to people? But often, as systems get more complex and involve more parties, they end up forced to use capability-ish designs, because ACL-based designs get intractable. OAuth's use of bearer tokens, for example, is very capability-ish, albeit not acknowledged as such, and a fairly primitive form of capabilities. This sort of design turns out to be necessary in large-scale systems. If people would learn capability theory before designing such systems, they'd probably be more secure and powerful.
- im_down_w_otp 9y ago
  Well... Kenton, now you've now got my brain stirring on whether or not the perceived complexity & opacity of ocap is an artifact of how tightly it has bound itself to the concepts of OOP (as something of a personal character flaw I find OOP to be fairly obfuscating beyond trivial domains for whatever reason), and whether or not FP concepts applied to a similar domain as ocap might provide me with clarity in security design/implementation the same way FP gave me clarity in program design/implementation eventually. None of which I really have excess time to noodle about, but is now unavoidable. Thank you, sir.
kmicklas 9y ago
IMO Unix is plenty bad enough to warrant replacement but unfortunately its iron grip on computing dooms any good ideas like capabilities in the short to medium term (at least 10 years).
gumby 9y ago
A big one is the cost of defense against forgery. A capability is essentially an index or pointer into a table in kernel space (much like an FD as another poster mentioned). The traditional mitigation is to use hardware tagging and permit the tag bits to be set only via a privileged instruction, e.g. Multics. The x86 segmented memory model also allowed this, and I used this to build some experimental SUID memory-mapped the 1990s (you could call into them via special gates, but not read the instruction memory, for example). Although you those memory models are still supported on x86 for back compatibility I don’t believe they are particularly fast any more, unfortunately. Edit: The lowrisc (RISC v) folks are implementing tagged memory also btw
- EtDybNuvCu 9y ago
  Capabilities are either unforgeable or unguessable, depending on your vantage point: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v...
- kentonv 9y ago
  Seems like you're talking about hardware capabilities, which haven't really been tried seriously since Intel's iAPX 432 processor in the early 80's. It failed miserably due to horrible performance, but some argue that the performance could have been fixed had they been given a second shot at it. Modern capability systems don't rely on hardware support and performance issues aren't usually cited as a problem with capabilities. In fact, capabilities can often perform better than ACLs since ACLs tend to require performing an expensive access check on every operation.
  - eb3c90 9y ago
    Thought it worth pointing out that Cheri are giving hardware capabilities another go. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
  - gumby 9y ago
    yes, I was talking about hardware tagging, else you can’t protect capabilities solely in user space. Intel had tagged memory in the 90’s era i960 as well and, as I edited my comment to mention (thanks to your comment!) several others including most recently RISC-V). IMHO the 432 had other structural problems and it wasn’t the tagging that killed it but it had enough problems that this is definitely not worth disagreeing about — perhaps that was indeed the straw that broke that camel’s back.
eb3c90 9y ago
They have got some adoption. Android security model is somewhat capability security based. However it is used in an insufficiently fine grained way. It does highlight some ways that it may not work if used for desktop, programs would just ask for large-grained capabilities (can I access all your pictures/files etc) and you get back to ambient style authority. I think expecting the user to be an intelligent judge of what capabilities a program needs, is not realistic. I think something like agoric auction of capabilities might force programs to provide useful features to get access to data, might work. I'm exploring it anyway.
- abecedarius 9y ago
  Marc Stiegler suggested having a set of standard authority bundles for when you're installing more or less standard app types. (Of course this raises the question of getting to a standard designed with users' interests in mind.) Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. (He made that suggestion back before Android etc. existed.) People are pretty OK at judging and tracking what to entrust other people with. This suggests the problem shouldn't be impossible, but that our interfaces don't map well to those familiar abilities.
  - jgtrosh 9y ago
    > Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. Isn't that similar to getting people used to installing anything they find on the web on Windows and just pressing accept for everything? I'd say a viable system needs to explicitly address special authority and make users are of it as an important thing, but still within the normal course of UX, to keep the distinction meaningful. The current state of Android is in the other direction: it explicitly addresses authority for many accesses, but they're not fine grain enough; so apps ask for a lot, getting people used to accept early without having a clear idea of what the app will do in the future, making it cheap for the programmer to ask for many accesses.
    - thingification 9y ago
deepnotderp 9y ago
Most C and C++ programs won't work then due to the way programmers have built them.
bsder 9y ago
Performance, mostly. Operating systems have tweaked the performance of user->kernel transitions to the point that anything placed on that path represents massive degradation in performance. Until we start having to pay performance for security, no one is going to bother. Meltdown and Spectre are really the first security attacks that will require significant amounts of performance to mitigate. Once we get enough of those kinds of attacks, people will start being willing to trade performance for security.
- kentonv 9y ago
  No, performance is not usually cited as a reason against capabilities. Capability-based authorization usually has near-negligible cost to evaluate -- certainly less than the cost of evaluating ACLs. The problem with capabilities is that you have to design your code differently to use them effectively.

urbit 9y ago

This is a great question. One possible answer: maybe the right system would use "ambient authority" (ACLs, etc) for the common case, but scale up to true capabilities for interesting corner cases. Creating capability UIs that compete, in the common case, with the normal ambient-authority design, is ferociously hard. This seems to be where most capability systems falter. The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Think about all the places you can type a filename or a URL. If the designator and the authorization have to travel together, and the pair is an unforgeable capability, then user-entered designators (like paths or URLs) are not practical. Designators can't travel through unsecured paths, through the human mind, etc. This is a painful limitation. That said, the OP is the best explanation of capabilities I've ever seen. Everyone really should read it.

kentonv 9y ago
> The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Heh, I'm not sure I'd describe Sandstorm as "leading" anything right now, but thanks. :) I think Sandstorm made the problem more difficult for itself by not just trying to solve this UI problem, but trying to do it in a way that can be integrated into existing codebases that were never designed with capabilities in mind. This is the really difficult part: dealing with legacy code. The powerbox itself is otherwise "just a picker", a fairly straightforward concept. For example, the standard file-open dialog box in everyone's browser, when invoked from an upload button on a web site, is actually a powerbox: the web site itself is given no access to any files except the one that the user chooses, but the file-open dialog is able to see everything. But imagine trying to graft this approach onto an existing native app, that is used to being able to read the hard drive directly and already has its own custom file picker UI built in. You have to convince the developers of that app to remove their nice custom UI and instead invoke the system's UI. Moreover, when they invoke the file picker, they now don't get back a file name, but rather an already-open file descriptor. So their code has to be adjusted to not expect a name. This could be hard, depending on how the code is organized: maybe it uses a bunch of libraries that expect to open a file by name, etc. Sandstorm is trying to graft this model onto apps that are used to making HTTP API requests to each other directly. We had designs figured out to make this work, and even make most of the process look like an OAuth request, so that existing OAuth-based apps might not need to change very much... some of this is implemented, but mostly we just didn't get there before running out of money. (I am still working on it in my spare time, though!)
- urbit 9y ago
  Protip: if no one's ahead of you, you're leading :-) This is a great answer. I think the impedance-mismatch question is a big part of the problem. Personally I prefer to boil the ocean rather than drowning in the impedance-mismatch tarpit. Both of these strategies are, of course, profoundly insane. It's true that a file-open dialog box easily becomes a powerbox. But of course, you are using the ambient authority of the user's login session to ascribe authority to the path that gets typed. So in a way it's the exception that proves the rule. And does a URL bar easily become a powerbox? What about a command-line shell? Perhaps we're both just agreeing that there is always trivial ambient authority, and the right way to scale up to nontrivial cases is a capability model. I just worry that when too many people discover the beautiful screwdriver that is capabilities, they decide that everything should be a screw. But the world has nails. It may even be true that the world should have nails. And then you find yourself pounding in nails with the butt of your screwdriver. Have you considered an ICO? Asking for a friend :-)
  - kentonv 9y ago
    I agree that capability people tend to get too extreme, and this tends to lead to failure. With Sandstorm we've tried to be more pragmatic, but still careful not to do anything that breaks the whole model in the long run. Whether or not the URL bar of a browser is a kind of powerbox depends on how extreme you want to get. In a pure capability model, yes, it would have to be. And hypertext would no longer be plain data -- it would be data with embedded capabilities (for each link), and would have to be transmitted via a protocol that can track capabilities. Obviously that kind of stuff, even though it would be amazingly powerful in a lot of ways, is not practical. :/ > Have you considered an ICO? Asking for a friend :-) People keep asking me that, often citing Urbit as an example to follow. :) At the moment I'm having too much fun at my day job building Cloudflare Workers (an unusually practical project by my standards!), and want to focus my outside-of-work time on coding Sandstorm rather than fundraising for it. In the future, who knows.
    - urbit 9y ago
      If I can distill my objection to the pure capability model: there are two different statements of the capability manifesto, one strong and one weak. The weak capability position is that it should be possible to construct an opaque combination of designator and authority, ie, a capability. The strong capability position is that designator and authority must always follow the same path. So in the "pure capability model," you are actually subtracting a feature from the system. Now, of course, it's often the case that subtracting a feature makes a system better. But one needs to be really clear about confusing this with the positive virtues of just having capabilities. Also, while I agree that capabilities are really great (Arvo has a somewhat capability-like internal communication model), it's important to point out that (a) capability vs. identity is a duality; and (b) it's cheating to compare a good capability system to a bad identity system. For (a), note that identity systems can implement capability features like delegation and revocation; they just have to do it actively rather than passively. If I am willing to act as your deputy, I can delegate my power to act to you. Or some restricted subset thereof. Tell me what to do and I'll do it. For (b), if you put a decent capability system next to the Internet, a network whose identity model is a burning-tire dumpster fire. If your identity system actually works and makes sense, competing is harder for the capability design. I do think Urbit should have some kind of capability model. However, this has the feel of a 2.0 or even 3.0 feature. I hate to solve a problem until it is actually in my way. I feel we have come nowhere near the limits of the common case. A simple map from identity to privilege is certainly that. And while capability UIs may be doable, identity UIs are trivial. This would not be the first case of humans being funky, hence screwing up our elegant architectural logic. If you have a system software project and it can advance without being lashed to a company, definitely do it that way! It's always a poor fit -- they have to succeed on different timelines. One thing I know: once we all have personal servers, today's cloud will look pretty lame in retrospect...
EtDybNuvCu 9y ago
Unforgeability can be weakened systematically to unguessability: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v... Unfortunately, the concept of "taming", where ambient-authority systems are used to implement functionality in capability-safe systems, is often a sad and frustrating path due to massive impedance mismatch. Like you say, paths are not caps, which means that capability-safe languages on UNIX-like systems are constantly dancing to tame the OS. As usual, it would be great if you made your VM cap-aware, so that we may eventually get over this hump.
- abecedarius 9y ago
  It's worth noting that WebAssembly should go nicely with capability systems. Mark S. Miller started a thread on the mailing lists recently about making sure it stays that way.

kentonv 9y ago

My opinion, as the designer of Sandstorm, a capability-based server OS: Capabilities are not the way developers are used to thinking. It may be that if people got used to it, it would make sense -- or it may be that it's simply too complicated and most developers will never wrap their heads around it. I honestly don't really know which it is. In this respect, it feels a lot like functional programming (FP and capabilities are very different concepts, but are similar in that it takes a while to fully understand how to use them effectively). We do see capability systems appearing by accident all over the place. Unix file descriptors, for example, behave very much like capabilities. Once open() finishes successfully, all access checks are done -- they aren't repeated for every read() or write(). You now have a capability, and you can even send that capability to other processes (even running under different UIDs that wouldn't have permission to open the file directly) via Unix domain sockets. People who really get how to exchange file descriptors build some amazing systems with them (without ever realizing they're building capability systems). But, for some reason, most systems do not really try to take advantage of FD passing, and instead opt to do things like listen on a globally-accessible port and perform an authentication handshake on incoming connections. I guess this kind of design just seems more obvious to people? But often, as systems get more complex and involve more parties, they end up forced to use capability-ish designs, because ACL-based designs get intractable. OAuth's use of bearer tokens, for example, is very capability-ish, albeit not acknowledged as such, and a fairly primitive form of capabilities. This sort of design turns out to be necessary in large-scale systems. If people would learn capability theory before designing such systems, they'd probably be more secure and powerful.

im_down_w_otp 9y ago
Well... Kenton, now you've now got my brain stirring on whether or not the perceived complexity & opacity of ocap is an artifact of how tightly it has bound itself to the concepts of OOP (as something of a personal character flaw I find OOP to be fairly obfuscating beyond trivial domains for whatever reason), and whether or not FP concepts applied to a similar domain as ocap might provide me with clarity in security design/implementation the same way FP gave me clarity in program design/implementation eventually. None of which I really have excess time to noodle about, but is now unavoidable. Thank you, sir.

kmicklas 9y ago

IMO Unix is plenty bad enough to warrant replacement but unfortunately its iron grip on computing dooms any good ideas like capabilities in the short to medium term (at least 10 years).

gumby 9y ago

A big one is the cost of defense against forgery. A capability is essentially an index or pointer into a table in kernel space (much like an FD as another poster mentioned). The traditional mitigation is to use hardware tagging and permit the tag bits to be set only via a privileged instruction, e.g. Multics. The x86 segmented memory model also allowed this, and I used this to build some experimental SUID memory-mapped the 1990s (you could call into them via special gates, but not read the instruction memory, for example). Although you those memory models are still supported on x86 for back compatibility I don’t believe they are particularly fast any more, unfortunately. Edit: The lowrisc (RISC v) folks are implementing tagged memory also btw

EtDybNuvCu 9y ago
Capabilities are either unforgeable or unguessable, depending on your vantage point: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v...
kentonv 9y ago
Seems like you're talking about hardware capabilities, which haven't really been tried seriously since Intel's iAPX 432 processor in the early 80's. It failed miserably due to horrible performance, but some argue that the performance could have been fixed had they been given a second shot at it. Modern capability systems don't rely on hardware support and performance issues aren't usually cited as a problem with capabilities. In fact, capabilities can often perform better than ACLs since ACLs tend to require performing an expensive access check on every operation.
- eb3c90 9y ago
  Thought it worth pointing out that Cheri are giving hardware capabilities another go. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- gumby 9y ago
  yes, I was talking about hardware tagging, else you can’t protect capabilities solely in user space. Intel had tagged memory in the 90’s era i960 as well and, as I edited my comment to mention (thanks to your comment!) several others including most recently RISC-V). IMHO the 432 had other structural problems and it wasn’t the tagging that killed it but it had enough problems that this is definitely not worth disagreeing about — perhaps that was indeed the straw that broke that camel’s back.

eb3c90 9y ago

They have got some adoption. Android security model is somewhat capability security based. However it is used in an insufficiently fine grained way. It does highlight some ways that it may not work if used for desktop, programs would just ask for large-grained capabilities (can I access all your pictures/files etc) and you get back to ambient style authority. I think expecting the user to be an intelligent judge of what capabilities a program needs, is not realistic. I think something like agoric auction of capabilities might force programs to provide useful features to get access to data, might work. I'm exploring it anyway.

abecedarius 9y ago
Marc Stiegler suggested having a set of standard authority bundles for when you're installing more or less standard app types. (Of course this raises the question of getting to a standard designed with users' interests in mind.) Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. (He made that suggestion back before Android etc. existed.) People are pretty OK at judging and tracking what to entrust other people with. This suggests the problem shouldn't be impossible, but that our interfaces don't map well to those familiar abilities.
- jgtrosh 9y ago
  > Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. Isn't that similar to getting people used to installing anything they find on the web on Windows and just pressing accept for everything? I'd say a viable system needs to explicitly address special authority and make users are of it as an important thing, but still within the normal course of UX, to keep the distinction meaningful. The current state of Android is in the other direction: it explicitly addresses authority for many accesses, but they're not fine grain enough; so apps ask for a lot, getting people used to accept early without having a clear idea of what the app will do in the future, making it cheap for the programmer to ask for many accesses.
  - thingification 9y ago

deepnotderp 9y ago

Most C and C++ programs won't work then due to the way programmers have built them.

bsder 9y ago

Performance, mostly. Operating systems have tweaked the performance of user->kernel transitions to the point that anything placed on that path represents massive degradation in performance. Until we start having to pay performance for security, no one is going to bother. Meltdown and Spectre are really the first security attacks that will require significant amounts of performance to mitigate. Once we get enough of those kinds of attacks, people will start being willing to trade performance for security.

kentonv 9y ago
No, performance is not usually cited as a reason against capabilities. Capability-based authorization usually has near-negligible cost to evaluate -- certainly less than the cost of evaluating ACLs. The problem with capabilities is that you have to design your code differently to use them effectively.