These are the slides from my DCDP 2010 keynote. Much of the presentation time was taken up by demos and Q&A, but the slides will give you a sense of the topics covered.

Using the Web for decentralized coordination of distributed processes.
You can get there from here.

At first blush, the Web might not seem like a good starting place for decentralized coordination of distributed processes. A typical Web application is vulnerable to multiple central authorities and so is not decentralized. Most often, coping with the travails of distribution depends upon human intervention via the browser's 'refresh' button; which doesn't bode well for headless processes. Coordination between Web applications, where it's done at all, often results in complete vulnerability between participants. Looking at the Web as a platform for decentralized coordination of distributed processes, it seems reasonable to conclude: "You can't get there from here".

Sometimes, a different perspective is all that is needed to find a way forward out of the maze. In this talk, we'll reacquaint ourselves with the Web's core technologies: the URL, HTTP and TLS. With a fresh outlook on these technologies, we'll explore how to use them for the desired effect, while still working within the existing Web infrastructure. Using simple and compatible extensions to the Web, we'll study cases where we can now coordinate the formerly intractable. The Waterken Server and an extended Web browser enable demonstration of these implementation techniques. With a different perspective on where "here" is, we'll get "there".

The Same Origin Policy is a mess. It cripples legitimate Web pages to messaging with only their own host, instead of the whole Web; yet is still rife with devastating security gotchas. The ground rules are setup to favor the attacker over the legitimate developer. The UMP is a first step towards a saner security model for the Web. In this first step, we cut both the restrictions and threats to cross-site messaging:

The Uniform Messaging Policy (UMP) enables cross-site messaging that avoids Cross-Site-Request-Forgery and similar attacks that abuse HTTP cookies and other credentials. For example, content from customer.example.org can safely specify requests to resources determined by service.example.com. Rather than restricting information retrieval to a single origin, as the Same Origin Policy almost does, the Uniform Messaging Policy supports origin independent messaging.

Mark Miller writes:

I just wanted to let you and everyone know that this is an *awesome* paper. Besides explaining Joe-E itself, it is perhaps the clearest and most powerful statement to date of the benefits provided by object-capability languages. I will be recommending this paper widely.

For some time now, a W3C Working Group has been working on access-control for cross-origin XMLHttpRequest. Since the requests are cross-origin, all the use-cases necessarily involve at least three distinct parties: the user's web browser, the site hosting the resource and the site making the request. As we know from "ACLs don't", it is impossible to express a correct solution to this problem using only the ACL model. Nevertheless, the WG is pursuing an ACL model solution based on the Origin proposal. The Origin proposal is essentially a degenerate form of stack introspection, where only two of the stack frames are inspected. An HTTP cookie identifies the principal associated with the top stack frame, and an Origin header is added by the web browser to identify a principal from one of the preceding stack frames. In the linked to email thread, we discuss how this solution fails when the stack is deeper than two levels. Not yet understanding the impossibility in their predicament, the WG is looking at moving to full stack introspection. Remaining CSRF vulnerabilities in full stack introspection are discussed in "ACLs don't".

Participants in the WG sometimes have a narrow view of what sites will want to use cross-origin requests for, so it can be a little tricky to devise compelling examples to demonstrate the Confused Deputy vulnerabilities in their proposal. Otherwise, this WG's work will provide an ongoing source of security vulnerabilities, so long as they continue using the ACL model. Proposals to at least provide support for non-ACL solutions have thus far been rebuffed.

When hosted by your server, the web_send library turns your Firebug console into a command line for your server-side application. The same code can also be run by the Windows Script Host, a standard part of all Windows releases since Windows 98. Doing so has two big advantages:

• no files need to be uploaded to your web server,
• you are not restricted by the Same Origin Policy.

As a result, you have a command line for all JSON resources on the Web. The world is at your fingertips!

This page explains how to use the JSON shell, with examples from Google, Yahoo!, Twitter and Flickr.

The web_send library provides a concise and expressive API for interacting with arbitrary JSON resources from the web browser. When used from the Firebug console, it acts like a command line for your web server; a great help during development of server-side code. The same API is also convenient for creating an AJAX user interface to JSON resources; so code born on the interactive command line migrates smoothly into application code. This tutorial also links to a live web page where you can try out the library against a simple server-side counter object.

The serverjs group is working on a set of APIs for server-side Javascript programming. I've joined in on a thread about an API for asynchronous operations. So far, the discussion has centered around the differences between the Deferred concept from Twisted and the promise concept from E and Barbara Liskov's work. Though I believe the Deferred concept is a direct descendant of the E promise, the API is significantly different and doesn't support the most useful programming idioms for asynchronous messaging. A Deferred doesn't support any operations that can't just as easily be done with promises. I'm hoping to convince the serverjs group to adopt promises instead of Deferreds; specifically, the Javascript ref_send library.

The ACL model is unable to make correct access decisions for interactions involving more than two principals, since required information is not retained across message sends. Though this deficiency has long been documented in the published literature, it is not widely understood. This logic error in the ACL model is exploited by both the clickjacking and Cross-Site Request Forgery attacks that affect many Web applications.

The announcement of the clickjacking research ignited interest in a number of Web exploits, some of which seem new and others similar to known exploits. Already, there's lots of discussion of possible workarounds, mainly focused on changes to the application's user interface, or the browser's rendering logic. While the flexibility of the browser's user interface languages gives clickjacking a polished look, this flexibility isn't actually what enables these attacks. That blame lies with the ambient authority model used by most web applications. If applications instead used an explicit authorization model, they would not be vulnerable to clickjacking and there would be no need to reduce the flexibility of the browser's user interface languages. Web applications can be implemented to an explicit authorization model without any change to Web protocols or formats.

I've ported the Petname Tool to the new Places API for bookmarks in Firefox 3.

Richard Conlan blogs about a SOUPS 2008 panel that I participated in.

Phil Windley blogs about my WWW 2008 presentation of the ref_send library for Javascript.

Any application that keeps state needs a plan for maintaining it as the application evolves. Successfully managing these upgrades is one of the more challenging aspects of application development. This document explains several patterns and techniques for managing upgrade in a Waterken application.

This publication completes my duties as editor for the W3C Web Security Context Working Group. I think the Problems with the status quo section provides a good summary of the challenges facing the group.

Mashups, web applications that interact with other web applications, are receiving increasing developer interest and providing users with valuable new functionality. When one or more of the interacting applications have access control requirements, many design challenges arise. Failure to meet these challenges brings unnecessary risk to the user. Addressing the challenges using a poorly suited technique can add significant complexity to both the application code and the user interface, all while not reducing risk to the user. In addition to examining and explaining these failings, this paper introduces a solution, the web-key, an https URL convention for representing a transferable permission in a web application. Using web-keys, access control challenges can be effectively solved using existing development tools for web applications deployed to existing web browsers.