that the untrusted client can influence control flow. Unlike
Swift, none of this prior work addresses client-side computation or helps decide which information and computation
can be securely placed on the client. Most of the prior work
only controls information flows arising from a single client
request, and not information flow arising across multiple
client actions or across sessions.
6. 2. unified Web application development
Several recently proposed languages provide a unified programming model for implementing applications that span
the multiple tiers found in Web applications. However,
none of these languages helps the user automatically satisfy
security requirements, nor do they support replication for
improved interactive performance.
Links5 and Hop19 are functional languages for writing
does this at the coarse granularity of individual functions,
whereas Hop allows individual expressions to be partitioned. Links supports partitioning program code into
SQL database queries, whereas Hop and Swift do not. Swift
does not have language support for database manipulation,
though a back-end database can be made accessible by
wrapping it with a Jif signature. Neither Links nor Hop helps
the programmer decide how to partition code securely.
Hilda24 is a high-level declarative language for developing
data-driven Web applications. It supports automatic partitioning with approximate performance optimization based
on linear programming. It does not support or enforce security policies, or replicate code or data. Hilda’s programming
model is based on SQL and is only suitable for data-driven
applications, as opposed to Swift’s more general Java-based
A number of popular Web application development
environments make Web application development easier
by allowing a higher-level language to be embedded into
HTML code. For example, JSP2 embeds Java code, and PHP18
and Ruby on Rails21 embed their respective languages. None
of these systems help to manage code placement, or help
to decide when client–server communication is secure, or
used directly). Programming is still awkward, and reasoning
about security is challenging.
The GWT18 makes construction of client-side code easier
server boundary, nor addresses security.
6. 3. automatic partitioning
That performance or security can be improved by
partitioning applications across distributed computing systems is an old idea and certainly not original to
Swift. Localizing security-critical functionality to trusted
components has been explored in limited contexts (e.g.,
Balfanz1). Coign11 partitions general systems automatically at the component level, though not according to
information security policies.
The key feature of Swift is that it provides security by
86 CommunICatIons of the aCm | febrUary 2009 | vol. 52 | no. 2
construction: the programmer specifies security requirements, and the system transforms the program to ensure
that these requirements are met. Some prior work has
explored this idea in other contexts.
The Jif/split system25, 26 also uses Jif as a source language
and transforms programs by placing code and data onto
sets of hosts in accordance with the labels in the source
code. Jif/split addresses the general problem of distributed
computation in a system incorporating mutual distrust and
arbitrary host trust relationships. Swift differs in exploring the challenges and opportunities of Web applications.
Swift uses specialized construction techniques that exploit
the trust assumptions it is based on. Supporting mutual
distrust between the client and server would be an interesting extension; for example, client state could be protected
in cookies. Replication is used by Jif/split only to boost
integrity, whereas Swift uses replication also to improve
Fournet and Rezk7 have shown that simple imperative programs annotated with confidentiality and integrity policies,
as in Jif/split, can be compiled into distributed, cryptographic
implementations that soundly enforce these policies.
We have shown that it is possible to build Web applications
that enforce security by construction, resulting in greater
security assurance. Further, Swift automatically takes care
of some awkward tasks: partitioning application functionality across the client–server boundary, and designing protocols for exchanging information. Thus, Swift satisfies three
important goals: enforcement of information security; a
dynamic, responsive user interface; and a uniform, general-purpose programming model. No prior system delivers
What is needed for technology like Swift to be adopted
widely? The two biggest impediments to adoption are first,
the added annotation burden of writing security annotations, and second, the inefficiency of bulk data transfers
between the server and the client.
Jif security annotations are mostly needed in method
declarations, where they augment the information specified
in existing type annotations. The Jif compiler is able to automatically infer most other annotations. In our experience,
the annotation burden is less than the burden of managing client–server communication explicitly, even ignoring
the effort that should be expended on manually reasoning
about security. More sophisticated type inference algorithms might lessen the annotation burden further.
Transferring data in bulk between the client and the server
can be less efficient than with a hand-coded implementation, because data transfers are tied to control transfers. The
Swift implementation ensures the client and server stacks
and heaps are in sync at each control transfer. It seems likely
that Swift could be extended with mechanisms for delaying
and securely batching updates to objects.
Because Web applications are being used for so many
important purposes, better methods are needed for building them securely. Swift embodies a promising approach for
this important problem.