A linear forwarder is a process that receives one message on a channel and sends it on a different channel. We use linear forwarders to provide a distributed implementation of Milner’s asynchronous pi calculus. Such a distributed implementation is known to be difficult due to input capability, where a received name is used as the subject of a subsequent input. This allows the dynamic creation of large input processes in the wrong place, thus requiring comparatively large code migrations in order to avoid consensus problems. Linear forwarders constitute a small atom of input capability that is easy to move. We show that the full input capability can be simply encoded using linear forwarders. We also design a distributed machine, demonstrating the ease with which we can implement the pi calculus using linear forwarders. We also show that linear forwarders allow for a simple encoding of distributed choice and have “clean” behaviour in the presence of failures.

We study behavioural equivalences for dynamic web data in Xd#, a model for reasoning about behaviour found in (for example) dynamic web page programming, applet interaction, and web-service orchestration. Xd# is based on an idealised model of semistructured data, and an extension of the #-calculus with locations and operations for interacting with data. The equivalences are non-standard due to the integration of data and processes, and the presence of locations. Contents 1

Distributed implementations of access control abound in distributed storage protocols. While such implementations are often accompanied by informal justifications of their correctness, our formal analysis reveals that their correctness can be tricky. In particular, we discover several subtleties in a state-of-the-art implementation based on capabilities, that can undermine correctness under a simple specification of access control. We consider both safety and security for correctness; loosely, safety requires that an implementation does not introduce unspecified behaviors, and security requires that an implementation preserves the specified behavioral equivalences. We show that a secure implementation of a static access policy already requires some care in order to prevent unspecified leaks of information about the access policy. A dynamic access policy causes further problems. For instance, if accesses can be dynamically granted then the implementation does not remain secure—it leaks information about the access policy. If accesses can be dynamically revoked then the implementation does not even remain safe. We show that a safe implementation is possible if a clock is introduced in the implementation. A secure implementation is possible if the specification is accordingly generalized. Our analysis shows how a distributed implementation can be systematically designed from a specification, guided by precise formal goals. While our results are based on formal criteria, we show how violations of each of those criteria can lead to real attacks. We distill the key ideas behind those attacks and propose corrections in terms of useful design principles. We show that other stateful computations can be distributed just as well using those principles. 1