3 ms·

> Isn't this now the standard reality for most desktop and mobile OSs? Not really, no. Because there isn't a comprehensive intent layer in the UI that is full

> Isn't this now the standard reality for most desktop and mobile OSs? Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities. Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail. Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation. > Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless. The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it. There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers. There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.

contingencies 6y ago
All good points. Clearly if reasonable security is a goal default trust should be restricted. Minimum trust thresholds should be distinct from sometimes-needed trust which should be delineated on a per-item/per-session/temporally restricted basis. Currently the way the web works, 1st party user downloading almost any 2nd party file means a 3rd party app of user-defined identity starts and reads the 2nd party file from a 4th party server in a 5th party format running on a 6th party OS with a 7th party network, 8th party browser and 9th+ party certificate chain in an unknown filesystem context. What is wrong with this picture? You can't establish trust in this context. All you can do is establish boundaries for failure. Modern history has shown that this tower-of-crap™ approach is the most commercially expedient means to distribute new functionality to general computing devices. I would argue that the path forward in general computing is therefore to work on processes to enhance and apply those restrictions using improved architectural decisions at the interface level combined with CI/CD processes that automatically apply them. In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.
- benlivengood 6y ago
  > In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage. Yep. This has to come from OS vendors and while iOS and Android took some steps in this direction they're still basically POSIX about it instead of capability-based. There's also a really unfortunate trend where apps want to be the entire user interface for everything. Manage the SMSs, be the camera and photos albums, handle payments, etc. This breaks all security guarantees by the OS.
kalleboo 6y ago
> A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail. Isn't this precisely how iOS works?

contingencies 6y ago

All good points. Clearly if reasonable security is a goal default trust should be restricted. Minimum trust thresholds should be distinct from sometimes-needed trust which should be delineated on a per-item/per-session/temporally restricted basis. Currently the way the web works, 1st party user downloading almost any 2nd party file means a 3rd party app of user-defined identity starts and reads the 2nd party file from a 4th party server in a 5th party format running on a 6th party OS with a 7th party network, 8th party browser and 9th+ party certificate chain in an unknown filesystem context. What is wrong with this picture? You can't establish trust in this context. All you can do is establish boundaries for failure. Modern history has shown that this tower-of-crap™ approach is the most commercially expedient means to distribute new functionality to general computing devices. I would argue that the path forward in general computing is therefore to work on processes to enhance and apply those restrictions using improved architectural decisions at the interface level combined with CI/CD processes that automatically apply them. In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.

benlivengood 6y ago
> In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage. Yep. This has to come from OS vendors and while iOS and Android took some steps in this direction they're still basically POSIX about it instead of capability-based. There's also a really unfortunate trend where apps want to be the entire user interface for everything. Manage the SMSs, be the camera and photos albums, handle payments, etc. This breaks all security guarantees by the OS.

kalleboo 6y ago

> A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail. Isn't this precisely how iOS works?