5 ms·

Anyone know when this was released? > largely dismissed by computer security reseachers and practitioners due to a history of misunderstandings seems incorrec

Anyone know when this was released? > largely dismissed by computer security reseachers and practitioners due to a history of misunderstandings seems incorrect now as virtually all web auth systems are capability based

david_draco 7y ago
HTML code says: Saturday, October 03, 1998
- ChrisSD 7y ago
  Presumably that's for the HTML template. The article has a citation from November 2002.
justincormack 7y ago
Which ones are?
- warkdarrior 7y ago
  Anything that uses OAuth2 is capability based.
ChrisSD 7y ago
~2003, assuming its related to the paper[0] of the same name (and sharing an author/diagrams). The paper was very influential and helped change minds on the subject. [0]: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
- erights 7y ago
  Yes, that's the paper, from 2003. Please everyone read this paper http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf rather than the web page. And thanks! There's a story behind why this paper became so influential. The paper was submitted to Usenix security and famously rejected https://web.archive.org/web/20160730083134/http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html https://web.archive.org/web/20160730083134/http://www.eros-o... Although we don't know who the specific reviewers were, they were from the Usenix Security program committee, and so from the elite of the field. This rejection captures perfectly the tone of dismissal common in academia at the time. The common wisdom was that capabilities were a failed and unworkable idea that we need not bother further discussing. As you can see from the date on that email, when we got this rejection, we immediately posted it publicly. My sense is that the paper together with this referee rejection, posted and discussed publicly, caused the initial influence. The embarrassment from that rejection was not on the authors. Within two years, many still thought capabilities were wrong. But the sneer was gone. Arguments could be heard. I dare say it marks the beginning of the capability revival in academia.
  - erights 7y ago
    Much of my work on capabilities, from 1988 till now, can be found at https://research.google/people/author35958/ https://research.google/people/author35958/ and at Agoric https://agoric.com/papers/ https://agoric.com/papers/ Agoric is bringing distributed object-capabilities to the modern world of decentralized crypto-commerce, including blockchains. Starting from object-capabilities, we're building a framework for highly composable smart contracts. Hack it at hackathon https://medium.com/agoric/spend-the-pandemic-inside-join-our-gitcoin-cross-chain-hackathon-and-win-prizes-d58e0437a874 https://medium.com/agoric/spend-the-pandemic-inside-join-our...
    - magicalhippo 7y ago
      > https://agoric.com/papers/ https://agoric.com/papers/ For someone who hadn't really read about this before, I found this[1] article, linked above, to be a really nice introduction. [1]: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/
  - szc 7y ago
    There are some real issues with implementing revokable capabilities on UNIX and Unix Like operating systems. For example, access to a file. Lets say you have a capability that grants file access. One can open the file and read and write to it when you have the capability. The file descriptor can be made to refuse access when the capability is revoked -- cutting off reads and writes, you'll really need a new error code for this as no others really explain what happened. However, this isn't enough, on UNIX systems that support mmap() your "access" capability now needs to be intertwined into the paging system, every page or mapping now has to be capability marked and checked. Paging is asynchronous, what happens when the capability is revoked? Is there now a hole in the address space of the process? How on earth do you communicate that to a process that might have pointer references into the mapped data? Which software programming language could support this? What happens when the process if forked? Does this duplicate the capability or not? Similar problems exist with shared memory and semaphores -- revoking an associated capability could deadlock a system. In my opinion, in order to make a system useable, a programmer or user must be able to build a mental model of how things work. Capabilities and resources suddenly disappearing is a challenging environment to work in. Just look at all the issues / problems that plague pluggable devices.
lidHanteyk 7y ago
Kind of. There's still a lot of work to do. OAuth and SAML are quite common, but they cannot federate capabilities; it is not trivial to issue somebody a capability to act on your behalf without an entire infrastructure of assistant services and trusted providers. That said, each decade looks better than the last, but I still encounter the myths covered in the paper, especially incorrect beliefs about revokation, on a regular basis.
say_it_as_it_is 7y ago
The opposite is true. Virtually no web auth systems are capability based. Maybe security SaaS providers are using it, but relatively spreading, they're not representative of the web proper.

david_draco 7y ago

HTML code says: Saturday, October 03, 1998

ChrisSD 7y ago
Presumably that's for the HTML template. The article has a citation from November 2002.

justincormack 7y ago

Which ones are?

warkdarrior 7y ago
Anything that uses OAuth2 is capability based.

ChrisSD 7y ago

~2003, assuming its related to the paper[0] of the same name (and sharing an author/diagrams). The paper was very influential and helped change minds on the subject. [0]: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf

erights 7y ago
Yes, that's the paper, from 2003. Please everyone read this paper http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf rather than the web page. And thanks! There's a story behind why this paper became so influential. The paper was submitted to Usenix security and famously rejected https://web.archive.org/web/20160730083134/http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html https://web.archive.org/web/20160730083134/http://www.eros-o... Although we don't know who the specific reviewers were, they were from the Usenix Security program committee, and so from the elite of the field. This rejection captures perfectly the tone of dismissal common in academia at the time. The common wisdom was that capabilities were a failed and unworkable idea that we need not bother further discussing. As you can see from the date on that email, when we got this rejection, we immediately posted it publicly. My sense is that the paper together with this referee rejection, posted and discussed publicly, caused the initial influence. The embarrassment from that rejection was not on the authors. Within two years, many still thought capabilities were wrong. But the sneer was gone. Arguments could be heard. I dare say it marks the beginning of the capability revival in academia.
- erights 7y ago
  Much of my work on capabilities, from 1988 till now, can be found at https://research.google/people/author35958/ https://research.google/people/author35958/ and at Agoric https://agoric.com/papers/ https://agoric.com/papers/ Agoric is bringing distributed object-capabilities to the modern world of decentralized crypto-commerce, including blockchains. Starting from object-capabilities, we're building a framework for highly composable smart contracts. Hack it at hackathon https://medium.com/agoric/spend-the-pandemic-inside-join-our-gitcoin-cross-chain-hackathon-and-win-prizes-d58e0437a874 https://medium.com/agoric/spend-the-pandemic-inside-join-our...
  - magicalhippo 7y ago
    > https://agoric.com/papers/ https://agoric.com/papers/ For someone who hadn't really read about this before, I found this[1] article, linked above, to be a really nice introduction. [1]: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/
- szc 7y ago
  There are some real issues with implementing revokable capabilities on UNIX and Unix Like operating systems. For example, access to a file. Lets say you have a capability that grants file access. One can open the file and read and write to it when you have the capability. The file descriptor can be made to refuse access when the capability is revoked -- cutting off reads and writes, you'll really need a new error code for this as no others really explain what happened. However, this isn't enough, on UNIX systems that support mmap() your "access" capability now needs to be intertwined into the paging system, every page or mapping now has to be capability marked and checked. Paging is asynchronous, what happens when the capability is revoked? Is there now a hole in the address space of the process? How on earth do you communicate that to a process that might have pointer references into the mapped data? Which software programming language could support this? What happens when the process if forked? Does this duplicate the capability or not? Similar problems exist with shared memory and semaphores -- revoking an associated capability could deadlock a system. In my opinion, in order to make a system useable, a programmer or user must be able to build a mental model of how things work. Capabilities and resources suddenly disappearing is a challenging environment to work in. Just look at all the issues / problems that plague pluggable devices.

lidHanteyk 7y ago

Kind of. There's still a lot of work to do. OAuth and SAML are quite common, but they cannot federate capabilities; it is not trivial to issue somebody a capability to act on your behalf without an entire infrastructure of assistant services and trusted providers. That said, each decade looks better than the last, but I still encounter the myths covered in the paper, especially incorrect beliefs about revokation, on a regular basis.

say_it_as_it_is 7y ago

The opposite is true. Virtually no web auth systems are capability based. Maybe security SaaS providers are using it, but relatively spreading, they're not representative of the web proper.