4 ms·

They have got some adoption. Android security model is somewhat capability security based. However it is used in an insufficiently fine grained way. It does hi

by eb3c90 9y ago

They have got some adoption. Android security model is somewhat capability security based. However it is used in an insufficiently fine grained way. It does highlight some ways that it may not work if used for desktop, programs would just ask for large-grained capabilities (can I access all your pictures/files etc) and you get back to ambient style authority. I think expecting the user to be an intelligent judge of what capabilities a program needs, is not realistic. I think something like agoric auction of capabilities might force programs to provide useful features to get access to data, might work. I'm exploring it anyway.

abecedarius 9y ago
Marc Stiegler suggested having a set of standard authority bundles for when you're installing more or less standard app types. (Of course this raises the question of getting to a standard designed with users' interests in mind.) Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. (He made that suggestion back before Android etc. existed.) People are pretty OK at judging and tracking what to entrust other people with. This suggests the problem shouldn't be impossible, but that our interfaces don't map well to those familiar abilities.
- jgtrosh 9y ago
  > Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. Isn't that similar to getting people used to installing anything they find on the web on Windows and just pressing accept for everything? I'd say a viable system needs to explicitly address special authority and make users are of it as an important thing, but still within the normal course of UX, to keep the distinction meaningful. The current state of Android is in the other direction: it explicitly addresses authority for many accesses, but they're not fine grain enough; so apps ask for a lot, getting people used to accept early without having a clear idea of what the app will do in the future, making it cheap for the programmer to ask for many accesses.
  - thingification 9y ago
    Right. The authority is not fine-grained enough because grants of authority are not dynamic (meaning they happen up front when the app is installed, not while the user is using the app). If the grants were dynamic, the context is clear to the user, who can therefore 1. understand what the grant is for 2. make an informed decision 3. use UI patterns like "powerbox" in which there is no "security UI", just UI that would be needed anyway. When that is true, finer-grained can be easier for the user, not harder. Of course there is more to it, e.g. kentonv's important point re substitutability. Some otherwise capable programmers don't seem to understand that point even in the domain of programming (as opposed to UI).
kentonv 9y ago
Assuming you mean the user-visible Android permissions model, a big problem with it, compared to object-capabilities, is that you can't choose among different implementations of each permission. E.g. if an app wants permission to listen to the microphone, you can't substitute a fake microphone that is always silent, or a virtual microphone provided by another app. You can only give it "the" microphone. The ability to substitute is critical to a good capability system, because it allows finer-grained control over what the app can or can't do. E.g. you could, say, implement a custom microphone that reads from the real microphone when you're out in public, but produces only silence when you're in your bedroom. Without the ability to substitute, we must rely on the OS designers to provide all possible options for us, and of course they don't care to implement many options. (OTOH, if you were talking about Intents, they are pretty capability-ish, though not always used well. Or if you were talking about some of the system internals like Binder, yeah, there's a bunch of capability-ish stuff in there.)

by eb3c90 9y ago

abecedarius 9y ago

Marc Stiegler suggested having a set of standard authority bundles for when you're installing more or less standard app types. (Of course this raises the question of getting to a standard designed with users' interests in mind.) Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. (He made that suggestion back before Android etc. existed.) People are pretty OK at judging and tracking what to entrust other people with. This suggests the problem shouldn't be impossible, but that our interfaces don't map well to those familiar abilities.

jgtrosh 9y ago
> Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. Isn't that similar to getting people used to installing anything they find on the web on Windows and just pressing accept for everything? I'd say a viable system needs to explicitly address special authority and make users are of it as an important thing, but still within the normal course of UX, to keep the distinction meaningful. The current state of Android is in the other direction: it explicitly addresses authority for many accesses, but they're not fine grain enough; so apps ask for a lot, getting people used to accept early without having a clear idea of what the app will do in the future, making it cheap for the programmer to ask for many accesses.
- thingification 9y ago
  Right. The authority is not fine-grained enough because grants of authority are not dynamic (meaning they happen up front when the app is installed, not while the user is using the app). If the grants were dynamic, the context is clear to the user, who can therefore 1. understand what the grant is for 2. make an informed decision 3. use UI patterns like "powerbox" in which there is no "security UI", just UI that would be needed anyway. When that is true, finer-grained can be easier for the user, not harder. Of course there is more to it, e.g. kentonv's important point re substitutability. Some otherwise capable programmers don't seem to understand that point even in the domain of programming (as opposed to UI).

kentonv 9y ago

Assuming you mean the user-visible Android permissions model, a big problem with it, compared to object-capabilities, is that you can't choose among different implementations of each permission. E.g. if an app wants permission to listen to the microphone, you can't substitute a fake microphone that is always silent, or a virtual microphone provided by another app. You can only give it "the" microphone. The ability to substitute is critical to a good capability system, because it allows finer-grained control over what the app can or can't do. E.g. you could, say, implement a custom microphone that reads from the real microphone when you're out in public, but produces only silence when you're in your bedroom. Without the ability to substitute, we must rely on the OS designers to provide all possible options for us, and of course they don't care to implement many options. (OTOH, if you were talking about Intents, they are pretty capability-ish, though not always used well. Or if you were talking about some of the system internals like Binder, yeah, there's a bunch of capability-ish stuff in there.)