Design

Labeled contexts

Today, developers use contexts (e.g., tabs, pages, and iframes) to isolate content from different origins (web sites). COWL extends contexts with labels, which encode the origins from which a context has read information. COWL then uses these labels to restrict how code within a context communicates: it confines the code to disallow any communication that would result in leaking an origin's sensitive data. COWL fits well with existing legacy web sites because it imposes these restrictions within the framework of existing discretionary access control (DAC) policies, such as the same-origin policy and CSP.

Labeled communication

To impose restrictions on how third-party code can use sensitive data, developers can label data before handing it off to a third-party context (e.g., using postMessage). When the third-party code later decides to use the data, COWL "taints" its context's label to confine the executing code. This approach differs from the status quo, in which the developer must effectively choose between benefiting from the functionality of the third-party code or risking the leaking of the sensitive data. With COWL, a developer can safely use third-party libraries by ensuring they are confined once granted access to sensitive information.

Privileges

In today's model, when the browser retrieves a page from https://example.com, any script within the context for the page is trusted not to violate the security concerns of https://example.com. This is natural: https://example.com should be allowed to dictate how its data is disseminated! In COWL, this notion of trust is made explicit with privileges. Privileges enable code to act on behalf of a page's origin and thus avoid becoming confined when reading data sensitive to that origin. Equally importantly, however, COWL allows code to "drop" its privileges or delegate them to other trustworthy code. Developers can use this primitive to build applications that adhere to the principle of least privilege.

These simple three primitives are amenable to a fast browser layout engine-level implementation, without any modifications to the underlying JavaScript engine. Moreover, because they extend already familiar concepts (e.g., contexts, postMessage, and XMLHttpRequest), we believe developers will find them a natural means for exerting additional control over the privacy of the data they curate. An example (see link above) illustrates how the COWL API can be used to confine a third-party password strength-checker library; our paper details three other common application design patterns.

Example: Confining a password strength-checker with COWL

COWL can be used to build several common types of application securely. Our paper describes several examples, including an encrypted document editor, an app that relies on jQuery, a third-party mashup, and a password strength checker. We will release the code for all of these soon, but for now let's see how we can confine a third-party library such as a password strength-checker.

Suppose the developer of the page https://example.com wants to use the password strength checker from http://sketchy.ru/checker.js. Maybe the developers at sketchy.ru are not malicious, but the developer doesn't trust them to write bug-free code. Note that the checker may need to communicate with sketchy.ru to fetch data that it needs to do its job. (For a more realistic library, e.g., the syntax highlighter running in this page, this is desirable functionality.) How does the developer use COWL to ensure that the checker won't leak a user's password to sketchy.ru or any other site?

   // In example.com page, create new context:
   var checker = new LWorker("http://sketchy.ru/checker.js");

   // In example.com page, register message handler waiting for result
   checker.onmessage = function(result) {
     console.log('Password is: ' + result.toString());
   };

   // Is the password sensitive? Yes, label it with example.com!
   var labeledPassword = new LabeledBlob(password, "http://example.com");
   // Send the checker the labeled password:
   checker.postMessage(labeledPassword);

  // In checker.js, register handler waiting for request from parent:
  onmessage = function(labeledPass) {
    if (doneLoading) {
      // Taint contex to preserve privacy or password
      COWL.privacyLabel = COWL.privacyLabel.and(labeledPass.privacy);
      // Now we can read the password
      var password = labeledPass.blob;
      // Cannot communicate with sketchy.ru anymore, but can reply to parent:
      postMessage(checkStrength(password));
    }
  };
  // .. use XHLHttpRequest to communicate with arbitrary sites