A Report on NSDI'13: Embassies: Radically Refactoring the Web

This is a report of the presentation done by Jon Howell on 2013-04-05. Paper co-authors are Jon Howell, Bryan Parno, and John R. Douceur, Microsoft Research. Paper received Best Paper Award.

"We literally saved the best for the last!" It was with these words that the session chair Krishna Gummadi introduced Jon Howell, co-author of the best paper award winner "Embassies: Radically Refactoring the Web". Jon promptly started his talk stating that the web promises us a really nice isolation model, in which users are protected from malice even though they click on "dangerous links". He said however that the reality is quite far from that nice isolation model, as browsers have vulnerabilities that might compromise the system, if explored by a malicious web app. In this scenario, what kind of advices one should give to ordinary web users? Practice "safe web-surfing hygiene"? Do not click on "dangerous links"? What does define a "dangerous links"?

According to Jon, these security weaknesses are not caused by poor web API implementation; even a correct browser implementation cannot protect users from external protocol flaws. "The API itself [is broken and] needs to be changed", he said. Why? He first explained that the web API has a subset of methods that specify the behavior of the application when it arrives at the client; for that subset he called Client Execution Interface (CEI). To provide application isolation, CEI must be as simple as possible and have a well-defined semantics, so that it can be implemented correctly; in other words, it should pursue minimality. He also explained that the same API has served as a Developer Programming Interface (DPI), and developers have always wanted this interface to be richer and richer, so that fancier applications can be built with less and less code; in other words, it has also been pursuing richness. "This API [is broken because it] has been pulled off in two opposite directions", he said. To solve this problem, he proposed to re-factor the web API, separating these roles of CEI and DPI. In this re-factored model, web developers would still use fancy programming interfaces (DPI), which could be made even richer; in separate, the client would implement a lower level, simpler, and more enforceable model (CEI), which would be minimal. How minimal? Well, Jon showed the entire interface using a single slide! In the paper, the complete interface counted 30 functions.

Jon illustrated that the CEI would provide web applications an execution environment having the same philosophy (and isolation guarantees) of a multi-tenant datacenter, but in the client machine -- a "pico-datacenter", as he defined. The CEI would include cryptographic primitives, so that applications could provide for themselves privacy and integrity. IP would be the only protocol for enabling communication between web apps and the network, and also between web apps running in the pico-datacenter. By choosing binary code as the core of the CEI, it would accept any binary program from the vendor. In this case, web developers would be able to develop their applications using the libraries that best suit their needs (e.g. libraries for HTML rendering, JavaScript processing, etc.); not only browser incompatibility is gone in this "Embassies" model, but users would also be able to run applications such as Gimp on their browsers! To run an application in the pico-datacenter, the client would just need to load the required libraries. In the remainder of the talk, Jon discussed about a number challenges faced in this Embassies model and how they are addressed; examples include cross-app interactions (e.g. form submission, cookies, coloring of visited hyperlinks, and history navigation), library caching, and launching performance. From an experimental evaluation using a prototype, the Embassies model has shown to introduce some overhead. However, he argued that this model brings several advantages; the pico-datacenter analogy, for example, makes security trade-offs more obvious to vendors. More importantly, he strongly emphasized that the overhead caused (which can be reduced, one should note) comes in exchange of a truthful web promise of a nice isolation model. "Dangerous links"? No more!

This ambitious, thought-provoking, and even controversial research (according to the best paper award committee) really caught the audience's attention! The question & answer session started in a fun atmosphere. As Nikita Borisov (University of Illinois at Urbana-Champaign) approached the microphone, Jon quickly apologized and said he had to leave and catch a flight, because he sensed a challenging question coming around. After some laughs, Nikita mentioned he saw some similarities between the Embassies model and the one that does exist in the mobile platform, and then asked Jon if the two models would eventually become one. Jon replied that he definitively sees convergence there, since the mobile world is being pushed towards the right user model. However, he thinks all the opportunities of this model are not being explored, since mobile apps do not depend on a clean and narrow execution interface. Someone (not identified) asked about the effectiveness of web-indexing in this new model, and the burden it would cause to vendors such as Google and Yahoo!. Jon answered that this is a reasonable aspect to be worried about, but said that while web app vendors can go anywhere they want (by using any shared libraries they please), they would still attach to popular transit protocols, and also expose interactions one will be able to sniff on. Lakshminarayanan Subramanian (New York University) proposed to take the work in a different way, and asked if there is a problem on how web pages should be designed. Jon suggested that a way one can look at this work is asking why the web API developers use to design their pages must be bounded to the browser, instead of being just software libraries they are free to choose. Jon said it is inevitable there will be complexity in the stack used to design web pages. The advantage is that web developers will be free to make choices over that complexity.