<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 10, 2015 at 4:52 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/02/2015 04:59 am, Ben Laurie wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Bill points out, this is exactly the point of capability systems (he<br>
didn't say it, but it is what he meant). A long time ago we had a choice<br>
between ACLs and capabilities, and we chose the wrong thing.<br>
<br>
Capability systems do exist, but we also have a lot of ACL-based<br>
engineering to fix in order to properly use them.<br>
</blockquote>
<br>
<br>
Having watched/worked with capability ideas for a while, I'm of the opinion they don't work as well in practice as the theoretical pundits would have it.<br>
<br>
Also, the users continue to demand ACLs.</blockquote><div><br></div><div>One other important thing to note: capabilities and ACLs aren't a dichotomy. You can use capabilities to implement ACLs.</div><div><br></div><div>As to why capabilities aren't more widely adopted, I think the most important thing is they're incredibly hard to retrofit. Once you go down the ambient authority road, turning back is very hard, because adding capabilities to a system that already implements ambient authority leaves you in the worst of both worlds.</div></div>
</div></div>