FANDOM


IntroductionEdit

Swift is a research web development framework created by Cornell University that lets web application developers build applications that are secure by construction. The developer writes a single Java application for both client and server code, annotated with labels that restrict which of client and server can access and modify data. Swift then partitions this code into a distributed program, running on both the client (using JavaScript) and the server (using JavaServer pages), which execute the web application using the Swift runtime.

MotivationEdit

Swift provides three main benefits to web application developers:

  • Security: Swift can significantly improve the security of existing applications by using information flow control theory. As we will see, Swift controls both explicit and more subtle implicit flows of information in the program, detecting subtle security flaws that even experienced programmers could miss, and forcing the programmer to explicitly declare every potentially insecure operation.
  • Interactivity: Swift’s partitioning algorithm tries to partition the code to minimize the number of network messages, and computation can be replicated in client and server if it reduces latency without thwarting security. This results in latencies very close to optimal, helping to develop interactive applications.
  • Simplicity: Developing Swift applications requires few skills beyond writing conventional computer programs. Developers are relieved of the low-level details of developing applications for a distributed client-server environment.

Architecture overviewEdit

Development and compilation processEdit

Swift-arch

Swift architecture

We now overview the development and compilation process of a Swift application:

  1. The programmer writes a program in the Swift language, which extends Java with labels. The programmer annotates the Java code with these labels to restrict the flow of information between variables.
  2. The Swift compiler performs static analysis on the code to check that information flows are safe, and annotates each statement of the program with placement constraints, which indicate whether the statement can execute on the client, server, or both.
  3. Swift partitions the code, estimating the control flow graph of the program and using integer programming techniques to minimize the number of client-server messages. Code that is safe to execute in either the client or server may be replicated in both if that reduces the number of messages, thus improving interactivity.
  4. The client code is translated to JavaScript using the Google Web Toolkit, while the server code runs as a Java program (JSP).
  5. Both client and server use the Swift runtime to run the web application.

In the rest of this write-up, we focus on explaining the Swift language and discussing the merits of the framework. Readers interested in the implementation details are welcome to consult the Swift paper.

Information flow control elementsEdit

Swift builds upon the powerful theory of information flow control. We present the main concepts here:

  1. Information labels: In Swift, every data element is tagged with a label. For example, consider the following declaration: int {server->server,client; server<-server} x;. The label, enclosed in braces, specifies two things:
    • A confidentiality policy (->): Who considers the data confidential, and who can access it. In our example, server->server,client indicates that x is considered confidential by server, and server and client can access it.
    • An integrity policy (<-): Who considers the data trusted, and who is allowed to modify it. In our example, server<-server indicates that x is considered trusted by server, and only server is allowed to modify it.
  2. Principals: In Swift, labels can include the principals or entities server and client. Additionally, the server is trusted by the client, so it can act for the client to bypass security policies. For example, int {client->client; client<-client,server} y; specifies that only the client should be able to access y. However, since the server is trusted, it can act for the client and access y as well. The converse is not true: in int {server->server; server<-server} z;, z is effectively private to the server and can't be accessed or modified by the client.
  3. Information flow control: Labels restrict how information flows in the program. For example, the statement x = y; causes an explicit information flow from y to x. This is secure if for every confidentiality policy in y, there is at least one as restrictive in x, and for every integrity policy in x, there is at least one as restrictive in y. In other words, information can only flow to increasingly confidential and decreasingly trusted variables. In addition, Swift also enforces secure implicit information flows. For example, in if (a > 0) x = y;, there is an implicit flow of information from a to x, because knowing that x and y have the same value would reveal that a > 0.
  4. Declassification and endorsement: If Swift only allowed secure flows, data would always be increasingly confidential and decreasingly trusted. For an application to be useful, flows that decrease confidentiality (declassification) or increase trust (endorsement) of data are necessary. Swift mandates that these potentially insecure flows are explicitly marked with declassify/endorse statements.

Example applicationEdit

Swift-dig

The Dig application

We illustrate the details of the Swift programming language with a simple application: a guessing game called 'Dig'. The user is presented with a 6x6 grid of squares (see the screenshot), and may click on them to uncover their contents. Each square can have one of three possible elements hidden beneath it: "$" (money), "@" (nothing), or "X" (a deadly trap). Obviously, the user cannot know the contents before clicking on the square. This game is a nice way to illustrate Swift because of the need to prevent the user from seeing the contents of the grid before clicking on a square. This idea can easily be extended more generally to web applications that need to hide some information from the client/browser.

We now present the code of the application. To build the client interface, the programmer instantiates a set of Swift widgets, which are GWT widgets extended to support Swift labels. We omit the code that instantiates these widgets from our example for the sake of simplicity. Also, we have abbreviated some parts of the code that don't contribute much to explaining the application and highlighting the features of Swift.

 public class Dig {
   <UI widget declarations>
   
   //Holds the contents of each square
   final private String[6][6] {server->server; server<-server} map;
   
   public Dig() {
     <create user interface>
     <initialize each cell of map to "X", "@" or "$">
   }
   
   //Called by client UI when a button is clicked
   public void digSquare(int{client->client,server;client<-client,server} row, col) {
   
       int{server->server; server<-server} trustedRow = endorse(row, {server->server; server<-server});
       int{server->server; server<-server} trustedCol = endorse(col, {server->server; server<-server});
       
       <validate that trustedRow, truestedCol are within bounds of map>
       
       String{server->server; server<-server} cell = map[trustedRow][trustedCol];
       
       if (cell == "X") {
         <notify the user that the game is over, finish the application>
       } else {
         String revealed = declassify(cell, {client->client,server;server<-server});
         <set the square that was clicked to the contents of revealed>
       }  
   }
   
   public static void main() {
       final Dig app = new Dig();
   }
 }


Note how local variables, class variables and method arguments are annotated with Swift labels. Other than this, the code is no different than a regular Java program. The variable map holds the contents of each square ("$", "@" or "X"). The client must neither see nor modify this variable, so we label it as accessible and modifiable only by the server.

The application first creates a Dig class, and runs the constructor method. This constructor both creates the client UI (panels, buttons, etc.) and initializes the contents of the map variable. The programmer does all this in a single method, but Swift will partition the code so that the client creates the UI and the server initializes the contents of map.

After the UI is created, when the user clicks on a cell, the digSquare method is called. The arguments of digSquare indicate the row and column of the clicked cell. We would like to use these to index the map table and retrieve the contents of the square. However, row and col have low integrity (note their client<-client,server integrity policy), so they cannot be used to index the higher-integrity map. To solve this, their integrity is raised (to server<-server) using endorse declarations. Note that only the server can perform endorsements. Finally, after obtaining the contents of the square by indexing map using trustedRow and trustedCol, we would like to reveal the content of that square to the client if the square is not an "X". However, the cell variable can only be accessed by the server (note the server->server confidentiality policy). To solve this, we declassify the contents of the cell variable to allow it to be accessed by the client. Finally, note that, as in the case of the constructor, Swift automatically partitions the digSquare method between the client and the server.

This simple example demonstrates how Swift can automatically partition an application between client and server, and how it enhances security by forcing the developer to explicitly declare potentially insecure information flows.

DiscussionEdit

What is good about Swift?Edit

  • Swift leverages information flow control theory and integer programming algorithms to improve security and interactivity of web applications. Swift also enhances simplicity by using just Java source code to generate client and server code, abstracting away the nuances of a distributed application from the programmer.

What are the downsides?Edit

  • Swift is definitely an unfinished product that is still in the research stage. Only a few Java classes and GWT widgets can be currently used in Swift applications. In attempting to write a custom Swift application, we ended up trying to hack the Swift framework source code to support additional functionality, which proved quite difficult. Therefore, Swift can only be used to build very simple applications, and it is not yet mature enough to support large, complex systems.
  • One promise of Swift is to automatically deliver security through the use of user-level directives about which data is trusted, confidential, etc. The downside of this approach is that the programmer is now required to have some basic principles of information flow control before he can write a correctly annotated program.
  • Swift is no substitute for a bad programmer. Although Swift requires programmers to explicitly declare potentially insecure flows, weak directives could still leave security holes in the web application.

What kinds of applications or environments would really benefit from Swift?Edit

  • Swift could be very useful in any application where water-tight security is mandatory and the programmers have good insight about the information flow control restrictions required to secure their program. For example, a gambling web application would require absolute security to ensure that rogue clients/browsers do not peek at the playing cards. Such absolute requirements for security could justify the complexities involved in code annotation. In its current state, however, Swift would not be appropriate for mass use by average programmers.

What could make Swift beneficial for mass use?Edit

  • Reduce the learning gap necessary to correctly annotate code. Perhaps Swift could provide some type of intelligent compiler support or front end that would make it easier to specify integrity and confidentiality policies for data and functions.
  • Swift has a strong focus on security, which probably makes it harder to learn. Instead, some features of the language could change to focus on the simplicity (abstracting away the complexity of a distributed application) and interactivity (minimizing the number of round trips) provided by the framework. For example, instead of requiring a label on every variable, Swift could have implicit default labels (global or per method), so that the programmer would only need to specify the labels that differ from the default one.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.