3 ms·

In every real-world security system I know of, if you share a sensitive document or photo to a friend, it is trivial for them to make a copy and share it widely

In every real-world security system I know of, if you share a sensitive document or photo to a friend, it is trivial for them to make a copy and share it widely. For example, if nothing else, they can copy/paste or take a screenshot. You rely on your friend to respect your wishes in not doing this; if you can't trust them, then you shouldn't share with them in the first place.

kentonv 9y ago
And regarding DRM: I see DRM as a UI technique, not security. You can create products whose UI is intentionally crippled in such a way that it becomes very hard to make copies of content. But at the end of the day, none of these systems are truly "secure", just inconvenient. You can do the same with capability-based systems, if you really want to.
EGreg 9y ago
Right, but in practice when you build some social app you may want to implement "banning someone from a chatroom" or "removing someone from your friends list" or "repudiating a stole device" and so on. So how do you do this? Let each friend have a unique capability such as "friend"? And then revoke them on the server side when someone is taken out of the group? In that case you again have a list of which friend is allowed to access a resource, aka an ACL. Which is what I was saying. Now you may say this is totally ineffective since that friend could ask another friend to be a proxy. But that's not very convenient usually, and involves violating various trust, which is auditable btw since we know whose capability was used. And also in a chatroom they won't be able anymore to speak in their own name, but only the proxy friend's name. Of course it's theoretically possible to still do stuff, but according to the capabilities motto, no one can be banned from a chatroom or from editing a document as long as SOMEONE can edit it.
- EtDybNuvCu 9y ago
  Capabilities support revocation: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf Capabilities support audit trails: http://www.erights.org/download/horton/document.pdf http://www.erights.org/download/horton/document.pdf I highly recommend that you read at least the first of these papers, "Demolishing Capability Myths", which directly addresses your point.
  - EGreg 9y ago
    I remember reading that paper, and also about CapROS and KeyKOS when it came out. I think there was also EROS back then. Whatever happened to them?
- kentonv 9y ago
  The capabilities model doesn't prohibit you from creating a UI that implements those features. It just acknowledges that you're making UI restrictions, you're not really prohibiting delegation, because prohibiting delegation is impossible. For example, a good capability-based sharing system should have a way for a user to indicate that resharing of some resource is not allowed. The effect of enabling this is that the regular sharing UI will be disabled for those people who "aren't supposed to" reshare. This UI might look exactly the same to the user as an ACL-based implementation would. This may sound "weaker" somehow than the ACL system, but it actually isn't, because neither system actually securely prevents resharing. Both merely make it inconvenient, forcing the user to go out of their way to break policy.

kentonv 9y ago

And regarding DRM: I see DRM as a UI technique, not security. You can create products whose UI is intentionally crippled in such a way that it becomes very hard to make copies of content. But at the end of the day, none of these systems are truly "secure", just inconvenient. You can do the same with capability-based systems, if you really want to.

EGreg 9y ago

Right, but in practice when you build some social app you may want to implement "banning someone from a chatroom" or "removing someone from your friends list" or "repudiating a stole device" and so on. So how do you do this? Let each friend have a unique capability such as "friend"? And then revoke them on the server side when someone is taken out of the group? In that case you again have a list of which friend is allowed to access a resource, aka an ACL. Which is what I was saying. Now you may say this is totally ineffective since that friend could ask another friend to be a proxy. But that's not very convenient usually, and involves violating various trust, which is auditable btw since we know whose capability was used. And also in a chatroom they won't be able anymore to speak in their own name, but only the proxy friend's name. Of course it's theoretically possible to still do stuff, but according to the capabilities motto, no one can be banned from a chatroom or from editing a document as long as SOMEONE can edit it.

EtDybNuvCu 9y ago
Capabilities support revocation: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf Capabilities support audit trails: http://www.erights.org/download/horton/document.pdf http://www.erights.org/download/horton/document.pdf I highly recommend that you read at least the first of these papers, "Demolishing Capability Myths", which directly addresses your point.
- EGreg 9y ago
  I remember reading that paper, and also about CapROS and KeyKOS when it came out. I think there was also EROS back then. Whatever happened to them?
kentonv 9y ago
The capabilities model doesn't prohibit you from creating a UI that implements those features. It just acknowledges that you're making UI restrictions, you're not really prohibiting delegation, because prohibiting delegation is impossible. For example, a good capability-based sharing system should have a way for a user to indicate that resharing of some resource is not allowed. The effect of enabling this is that the regular sharing UI will be disabled for those people who "aren't supposed to" reshare. This UI might look exactly the same to the user as an ACL-based implementation would. This may sound "weaker" somehow than the ACL system, but it actually isn't, because neither system actually securely prevents resharing. Both merely make it inconvenient, forcing the user to go out of their way to break policy.