2 comments

  • jFriedensreich1 hour ago
    The &quot;permissions as access&#x2F;visibility&quot; is unfortunately not holding up in practice. As nice as a simplification like this would be: No one wants to configure up front what permissions are needed. Users will run into annoyances and then just overcommit resource access the same way they choose to run yolo mode. Limiting access for security is a great part of a capability based system but a system that will be used in the way intended needs the following properties, which are mostly missing from the tools we have (apparmor, seccomp, oss VMs, seatbelt, docker, bubblewrap etc.)<p>- pause execution for a policy engine or user input<p>- variable scope permissions independent of what was requested. eg user needs to allow just this request to &#x2F;test&#x2F;myfile.txt or grant &#x2F;test&#x2F;* in that moment<p>- add (ideally also remove) capabilities based on dynamic user input or engine decisions without up front configuration<p>- not need application support, if apps need to support it the moment the harness uses an external tool the model breaks<p>deno, workerd and maybe a vm&#x2F;docker solution with an webdav proxy mount and web-proxy are the only environments i am aware of where systems like this could be build at all, even there, with limitations. (Not writing this to sound absolute but to learn about other options I am missing.)
  • juancn1 hour ago
    &quot;Perfection is finally attained, not when there&#x27;s nothing else to add, but when there&#x27;s nothing else to remove&quot;<p>- Antoine de Saint-Exupéry
    • grim_io59 minutes ago
      Could have started with his name, jeez.<p>jk