3 ms·

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

by flukus 9y ago

thingification 9y ago
Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. Capability security has low adoption in part because of the usual catch-22 (adoption breeds adoption), in part because it's a tricky challenge to retrofit, and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.
- flukus 9y ago
  > and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have to prompt the user or does it have to have to be granted the access at install time? As far as I'm aware those are the only two options. > The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. It sounds like it has to prompt users to get permissions: > This includes a KDE-based PowerBox scheme allowing sandboxed applications to request user-driven file open using standard dialogs.
  - thingification 9y ago
    > It sounds like it has to prompt users to get permissions: Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place. As long as the thing that is being granted access is isolated and nothing else grants it access, problem solved. It's a very neat idea, and it works. This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority". Here's an old talk with demonstrations by Marc Stiegler, who I believe came up with the concept: https://www.youtube.com/watch?v=vrbmMPlCp3U https://www.youtube.com/watch?v=vrbmMPlCp3U More recently I hear essentially the same idea has been used in mobile phone security (I don't have that kind of mobile phone). The capability ideas that surround it are not widely known or understood, though.
    - flukus 9y ago
      Thanks for the video, I'll give it a watch when I'm not at work, so apologies if any of the below is covered by the video. > Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place. That's fine in simple cases, windows store apps already work this way, but what about something like an IDE where you want to open many files? I suppose granting permission at a folder level is possible, but then what about something like vim where I want to switch between files and there is no file open dialog? What happens when I want to install an a different file browser that needs global read/write abilities? > This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority". How does that work with something like an IDE? You have to pass the compiler a bunch of files names and you'd have to pass the access permission with them, then compiler has to create a new executable with the ability to run and pass the access back to the IDE. And that's just for the simple case. For that matter, how does it work with command line tools that pipe file names between them? Every demo and implementation I've seen appears to be under the impression that apps are self contained.

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

by flukus 9y ago

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. Capability security has low adoption in part because of the usual catch-22 (adoption breeds adoption), in part because it's a tricky challenge to retrofit, and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.

flukus 9y ago
> and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have to prompt the user or does it have to have to be granted the access at install time? As far as I'm aware those are the only two options. > The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course. It sounds like it has to prompt users to get permissions: > This includes a KDE-based PowerBox scheme allowing sandboxed applications to request user-driven file open using standard dialogs.
- thingification 9y ago
  > It sounds like it has to prompt users to get permissions: Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place. As long as the thing that is being granted access is isolated and nothing else grants it access, problem solved. It's a very neat idea, and it works. This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority". Here's an old talk with demonstrations by Marc Stiegler, who I believe came up with the concept: https://www.youtube.com/watch?v=vrbmMPlCp3U https://www.youtube.com/watch?v=vrbmMPlCp3U More recently I hear essentially the same idea has been used in mobile phone security (I don't have that kind of mobile phone). The capability ideas that surround it are not widely known or understood, though.
  - flukus 9y ago
    Thanks for the video, I'll give it a watch when I'm not at work, so apologies if any of the below is covered by the video. > Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place. That's fine in simple cases, windows store apps already work this way, but what about something like an IDE where you want to open many files? I suppose granting permission at a folder level is possible, but then what about something like vim where I want to switch between files and there is no file open dialog? What happens when I want to install an a different file browser that needs global read/write abilities? > This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority". How does that work with something like an IDE? You have to pass the compiler a bunch of files names and you'd have to pass the access permission with them, then compiler has to create a new executable with the ability to run and pass the access back to the IDE. And that's just for the simple case. For that matter, how does it work with command line tools that pipe file names between them? Every demo and implementation I've seen appears to be under the impression that apps are self contained.