Meltdown and Spectre are serious. But we need clarity on what they do and do not threaten. To address the widespread confusion on this topic, and to demonstrate a completely different approach to mitigating these, we wrote:
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.
At https://twitter.com/spudowiar/status/1069680974110306306 Saleem Rashid raises an example of this principle that is especially easy to overlook, where authority arises from one entity relying on the unchecked veracity of another.
In light of some feedback we've received on the article, some
clarification is needed. The ocap (object-capabilities) approach does
not by itself make systems secure. Rather, it an enormous step
towards making systems secureable. Even after taking this step, making
complex systems secure can still be very hard, depending on the
specifics.
In an ocap system such as SES https://github.com/Agoric/SES , an
object can only directly cause effects on the world outside itself by
using the capabilities it holds. Objects come in graphs held together
by references, so an object can still only cause effects, directly or
indirectly, according to its connectivity to the rest of the system
via references. The different between direct effects vs general
causation is the difference between permission and authority
[1,2]. Permission is often vastly easier to reason about than
authority, but our safety depends on reasoning about limits on
authority.
The event-stream exploit would have been prevented merely by practicing
the principle of least permission. Hence this article did not need to
go into these subtleties. Hence, this exploit is a good example for
introducing people to these concepts, tempting them to dig deeper [3].
This npm / event-stream incident is the perfect teaching moment for POLA (Principle of Least Authority), and for the need to support least authority for JavaScript libraries.
https://agoric.com/taxonomy-of-security-issues/ and https://ses-demo.netlify.app/demos/challenge/