On the server, said Livshits, "if you have to run the replica within a browser, you would incur a memory footprint of 50 to 60 megabytes per browser instance." The solution that he and Kiciman devised was to instead run a "headless browser"--an emulator that simulates only the functions of a Web browser essential to Ripley. This drove down the memory footprint of the cloned browser and application to between one and one and a half megabytes per application.

By shrinking the server-side clone of the user's browser-based application, Livshits and Kiciman--together with colleagues from Cornell University, NY and the Indian Institute of Technology, Delhi--reduced the performance overhead of Ripley further still. Out of five experimental applications, which included a shopping cart, several games, and a blogging engine, the average increase in latency due to the increased efforts of the server's CPU was around one millisecond.

In some cases, Ripley even enhanced the performance of Web applications, because the server-side clone of the client application is rewritten in .NET, a programming language that is 10 to 100 times faster than the JavaScript running on the client side. Sometimes this allows Ripley to predict what the next client-side application request will be before it has even been made by the client, and preemptively push data to the client.

"This is a magical situation, if you think about it," says Livshits. "It leads to zero latency remote procedure calls."

At present, developers interested in using Ripley to secure their Web applications would have to reimplement the ideas in the paper presented on Ripley on their own favorite Web application framework. Eventually however, Livshits and Kiciman think Ripley could help democratize an essential part of Web application security, putting it within reach of non-expert developers.

"Up until now I think people have attacked these problems manually," says Kiciman. "You get experts who dive in and they tailor their applications to meet these challenges, but that's not very scalable, and not very agile when you need to make changes. What we're trying to do is get the Web development platform to a point where anyone can take advantage of the types of technology these experts are using."

UC Berkeley's Barth notes that Ripley is part of a larger trend in solutions that protect the integrity of client-side code by assuring that no unauthorized behavior can occur. "I see Ripley as more of a thought experiment: What would happen if the server validated everything?" he says. "The work suggests that security would benefit if we validated more than we're validating today."