erights

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:

https://agoric.com/taxonomy-of-security-issues/ and https://ses-demo.netlify.app/demos/challenge/

> were you one of the authors, contributors or involved in writing it?

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.

Hi Ping! What differences do you find most striking?

Much of my work on capabilities, from 1988 till now, can be found at https://research.google/people/author35958/ and at Agoric 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...

Yes, that's the paper, from 2003. Please everyone read this paper 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-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.

ActivityPub is important. We need it to be more widely appreciated. I'm glad to see it on Hacker News.

Chris Webber, one of ActivityPub's creators, suggests next steps in "OcapPub: Towards networks of consent" https://gitlab.com/spritely/ocappub/blob/master/README.org

Chris and I gave keynotes at ActivityPub 2019:

"ActivityPub: past, present, future" by Chris https://www.youtube.com/watch?v=Tgq0lqZ1Mvw

"Architectures of Open Robustness" by me https://www.youtube.com/watch?v=NAfjEnu6R2g&list=PLzDw4TTug5...

Thanks. The "with(proxy)" part specifically would be mine. The old Google Caja, from the EcmaScript-5 days preceding Proxies, did something similar: https://github.com/google/caja/blob/master/src/com/google/ca...

The full new pattern, combining "with(proxy)" with a clever use of direct "eval", is from Caridy Patino of Salesforce.

The modern Realms Shim https://github.com/Agoric/realms-shim , and the SES Shim which builds on it https://github.com/Agoric/SES , is a collaboration of Agoric and Salesforce, especially JF Paradis of Salesforce.

We have come to refer to the fragment of code with the "with(proxy)" and the direct "eval" as the "Eight magic lines of code" and "The heart of the shim". It is explained at https://www.youtube.com/watch?v=9Snbss_tawI&list=PLKr-mvz8uv... and https://www.youtube.com/watch?v=mSNxsn0pK74&list=PLKr-mvz8uv...

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].

[1] Paradigm Regained http://www.erights.org/talks/asian03/paradigm-revised.pdf

[2] Permission and Authority Revisited https://ai.google/research/pubs/pub45570

[3] References page https://agoric.com/references/

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://www.youtube.com/watch?v=9Snbss_tawI&list=PLKr-mvz8uv... is my presentation to the Node security team, explaining many of these issues prior to this particular incident.