3 ms·

Indeed, one of the maxims of capability-based security is "don't try to prohibit what you can't prevent".

EGreg 9y ago
So when you have a sensitive document or a photo you only want to share with 20 friends, you should make it easy for it to get out? In other words the capabilities maxim implies that privacy and DRM should not exist.
- EtDybNuvCu 9y ago
  Formally, DRM cannot work in capability-based systems, just like it cannot work in ACL-based systems. The proofs are pretty easy, depending on the system's primitives, and are akin to the standard proof using "real" bit-based digital logic: Information, being inherently copyable, cannot be protected from exfiltration by any agent which sees the information, even only once. Privacy, on the other hand, works fine. The model used by the E family of capability-safe languages, like E-on-Java and Monte, allows for a compute node to be totally isolated aside from The Network, an abstract message-passing I/O interface. The resulting model grants nodes privacy within themselves by default. If you want your code and data to be private, do not put them on machines which you do not control. If you want certain friends to not reshare private photos, do not show those friends those photos. If you have a secret, and you tell somebody, it's no longer a secret.
- noblethrasher 9y ago
  You cannot prevent one or more of your friends from being a proxy for someone that is not one of your friends. On the other hand, you can log everything, which renders propositions like "I can trust friend X not to share resource Y" falsifiable (i.e. scientific/testable). Personal computing is the thing that is antagonistic to DRM, where "computer" means "can simulate anything, including a better computer", and where "better" means a computer that does what I want, including ignoring DRM.
- kentonv 9y ago
  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.

So when you have a sensitive document or a photo you only want to share with 20 friends, you should make it easy for it to get out? In other words the capabilities maxim implies that privacy and DRM should not exist.

EtDybNuvCu 9y ago
Formally, DRM cannot work in capability-based systems, just like it cannot work in ACL-based systems. The proofs are pretty easy, depending on the system's primitives, and are akin to the standard proof using "real" bit-based digital logic: Information, being inherently copyable, cannot be protected from exfiltration by any agent which sees the information, even only once. Privacy, on the other hand, works fine. The model used by the E family of capability-safe languages, like E-on-Java and Monte, allows for a compute node to be totally isolated aside from The Network, an abstract message-passing I/O interface. The resulting model grants nodes privacy within themselves by default. If you want your code and data to be private, do not put them on machines which you do not control. If you want certain friends to not reshare private photos, do not show those friends those photos. If you have a secret, and you tell somebody, it's no longer a secret.
noblethrasher 9y ago
You cannot prevent one or more of your friends from being a proxy for someone that is not one of your friends. On the other hand, you can log everything, which renders propositions like "I can trust friend X not to share resource Y" falsifiable (i.e. scientific/testable). Personal computing is the thing that is antagonistic to DRM, where "computer" means "can simulate anything, including a better computer", and where "better" means a computer that does what I want, including ignoring DRM.
kentonv 9y ago
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.