3 ms·

>Unfortunately 30ish years on, people still don't seem in general to understand capabilities That's because they think they've seen it, and what they saw was h

>Unfortunately 30ish years on, people still don't seem in general to understand capabilities That's because they think they've seen it, and what they saw was horrible. First was the UAC stuff in Windows Vista that caused no end of unnecessary headaches. Next was all of the permissions flags (capabilities) in their phones in the name of "security" It's a Java/Javascript situation. I'm not sure what the best way to route around this is. Recently I've used these analogies: Cash in a wallet - if you hand someone $10, there's no way that it can lead to a loss of more than $10, as opposed to access to your entire wallet Circuit breaker / Outlet - An circuit is only capable of delivering up to the limit of the circuit breaker that is protecting it

cmrdporcupine 4y ago
Yes the conceptual model behind capabilities is perhaps the hardest part to understand fully, and completely translate back to end users. We're so used to this "identity" and "API" separation now, we just take it for granted. And I suspect it has a lot to do with our own mental modeling of problem domains like they're hierarchical social problems. Administrator is the King and He Can Do All. Others are Serfs. Whatever. The notion that the "handle" or "reference" is the capability and the API itself is the 'permissions' layer is harder to explain maybe. I still struggle fully with the vocabulary around it.
- mikewarot 4y ago
  See here's how I explained it in another thread - https://news.ycombinator.com/item?id=32740498 https://news.ycombinator.com/item?id=32740498 Capability Based Security - No, you really don't know what it is (like Java/Javascript, there's confusion.. it's not Windows Vista UAC, nor the flags for apps on your phone, not even AppArmor or SElinux) Currently, when you start your favorite GUI based editor, and tell it to open a file, it calls on the OS to present a dialog box, who chooses file(s), those names are then passed back to the editor. The editor then uses the users permission to open the file(s), and allow you to edit your data. Note that there is NOTHING stopping the program from getting confused or malicious and opening any arbitrary file using that user's account. The exact same workflow happens in a Capabilities based OS, except the names of the parts and constraints (that you don't see) are different. It works exactly the same, as far as the user is concerned. Instead of calling on the OS to present a dialog, then directly accessing the files, the program calls the OS to present a PowerBox to the user, and it returns capabilities to files or folders, the program has NO access to any other folders or files. No matter how confused or rogue the editor can not corrupt anything outside of the objects specifically chosen by the user.

cmrdporcupine 4y ago

Yes the conceptual model behind capabilities is perhaps the hardest part to understand fully, and completely translate back to end users. We're so used to this "identity" and "API" separation now, we just take it for granted. And I suspect it has a lot to do with our own mental modeling of problem domains like they're hierarchical social problems. Administrator is the King and He Can Do All. Others are Serfs. Whatever. The notion that the "handle" or "reference" is the capability and the API itself is the 'permissions' layer is harder to explain maybe. I still struggle fully with the vocabulary around it.

mikewarot 4y ago
See here's how I explained it in another thread - https://news.ycombinator.com/item?id=32740498 https://news.ycombinator.com/item?id=32740498 Capability Based Security - No, you really don't know what it is (like Java/Javascript, there's confusion.. it's not Windows Vista UAC, nor the flags for apps on your phone, not even AppArmor or SElinux) Currently, when you start your favorite GUI based editor, and tell it to open a file, it calls on the OS to present a dialog box, who chooses file(s), those names are then passed back to the editor. The editor then uses the users permission to open the file(s), and allow you to edit your data. Note that there is NOTHING stopping the program from getting confused or malicious and opening any arbitrary file using that user's account. The exact same workflow happens in a Capabilities based OS, except the names of the parts and constraints (that you don't see) are different. It works exactly the same, as far as the user is concerned. Instead of calling on the OS to present a dialog, then directly accessing the files, the program calls the OS to present a PowerBox to the user, and it returns capabilities to files or folders, the program has NO access to any other folders or files. No matter how confused or rogue the editor can not corrupt anything outside of the objects specifically chosen by the user.