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-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.
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/
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.
I have read the paper, and the rejection notes you linked to, and I can't evaluate them (lack of time + lack of experience in this field) but they don't come across as snooty dismissals. Feels more like guys on all sides trying their best.
Yes, I am one of the authors of the paper.
> but they don't come across as snooty dismissals. Feels more like guys on all sides trying their best.
Rereading it now, it's mixed. I definitely have a milder reaction than I did at the time. Thanks for challenging me on this.
[0]: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf