Controlled sharing is fundamental to distributed systems; yet, on the Web, and in the Cloud, sharing is still based on rudimentary mechanisms. More flexible, decentralized cryptographic authorization credentials have not been adopted, largely because their mechanisms have not been incrementally deployable, simple enough, or efficient enough to implement across the relevant systems and devices. This paper introduces macaroons: flexible authorization credentials for Cloud services that support decentralized delegation between principals. Macaroons are based on a construction that uses nested, chained MACs (e.g., HMACs [43]) in a manner that is highly efficient, easy to deploy, and widely applicable. Although macaroons are bearer credentials, like Web cookies, macaroons embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests. This paper describes macaroons and motivates their design, compares them to other credential systems, such as cookies and SPKI/SDSI [14], evaluates and measures a prototype implementation, and discusses practical security and application considerations. In particular, it is considered how macaroons can enable more fine-grained authorization in the Cloud, e.g., by strengthening mechanisms like OAuth2 [17], and a formalization of macaroons is given in authorization logic. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

We present S5, a semantics for the strict mode of the ECMAScript 5.1 (JavaScript) programming language. S5 shrinks the large source language into a manageable core through an implemented transformation. The resulting specification has been tested against realworld conformance suites for the language. This paper focuses on two aspects of S5: accessors (getters and setters) and eval. Since these features are complex and subtle in JavaScript, they warrant special study. Variations on both features are found in several other programming languages, so their study is likely to have broad applicability.

No abstract

Web pages routinely incorporate JavaScript code from third-party sources. However, all code in a page runs in the same security context, regardless of provenance. When Web pages incorporate third-party JavaScript without any checks, as many do, they open themselves to attack. A third-party can trivially inject malicious JavaScript into such a page, causing all manner of harm. Several such attacks have occurred in the wild on prominent, commercial Web sites.A Web sandbox mitigates the threat of malicious JavaScript. Several Web sandboxes employ closely related language-based techniques to maintain backward-compatibility with old browsers and to provide fine-grained control. Unfortunately, due to the size and complexity of the Web platform and several subtleties of JavaScript, language-based sandboxing is hard and the Web sandboxes currently deployed on major Web sites do not come with any formal guarantees. Instead, they are routinely affected by bugs that violate their intended sandboxing properties.This article presents a type-based approach to verifying Web sandboxes, using a JavaScript typechecker to encode and verify sandboxing properties. We demonstrate our approach by applying it to the ADsafe Web sandbox. Specifically, we verify several key properties of ADsafe, falsify one intended property, and find and fix several vulnerabilities, ultimately providing a proof of ADsafe's safety.

We present S5, a semantics for the strict mode of the ECMAScript 5.1 (JavaScript) programming language. S5 shrinks the large source language into a manageable core through an implemented transformation. The resulting specification has been tested against real-world conformance suites for the language. This paper focuses on two aspects of S5: accessors (getters and setters) and eval. Since these features are complex and subtle in JavaScript, they warrant special study. Variations on both features are found in several other programming languages, so their study is likely to have broad applicability.

No abstract

JavaScript programs vary widely in functionality, complexity, and use, and analyses of these programs must accommodate such variations. Type-based analyses are typically the simplest such analyses, but due to the language's subtle idioms and many application-specific needs-such as ensuring general-purpose type correctness, security properties, or proper library usage-we have found that a single type system does not suffice for all purposes. However, these varied uses still share many reusable common elements.In this paper we present TeJaS, a framework for building type systems for JavaScript. TeJaS has been engineered modularly to encourage experimentation. Its initial type environment is reified, to admit easy modeling of the various execution contexts of JavaScript programs, and its type language and typing rules are extensible, to enable variations of the type system to be constructed easily.The paper presents the base TeJaS type system, which performs traditional type-checking for JavaScript. Because JavaScript demands complex types, we explain several design decisions to improve user ergonomics. We then describe TeJaS's modular structure, and illustrate it by reconstructing the essence of a very different type system for JavaScript. Systems built from TeJaS have been applied to several real-world, third-party JavaScript programs.There is a venerable line of research on retrofitting type systems onto previously "untyped" languages, with Morris's seminal dissertation [11] an early example. In practice, these languages are not actually free of types; rather, all type discrimination is performed by primitive operations at runtime. A common practice for retrofitting type systems has been to identify the resulting set of run-time errors and try to eliminate them statically. For instance, Smalltalk type systems [1, 22] focused on eliminating message-not-found errors, and Soft Scheme [25] addressed the wide range of Scheme dynamic errors. Identifying run-time errors and catching them statically can be viewed as the design principle for retrofitted type systems.Unfortunately, this principle is rather difficult to apply to JavaScript (JS), because there are so few actual run-time errors. 1 In this, JS inherits the forgiving mentality of the browser environment where it was born; instead of flagging errors and halting execution, it simply continues running. As a result, operations that in other languages might reasonably be expected to generate errors do not in JS: subtracting one string from another, accessing an array outside its bounds, reading and writing non-existent fields, calling functions with the wrong number of arguments, etc.Obviously, every one of these operations has a welldefined semantics in JS (usually, ironically, involving the value undefined). Therefore, it becomes a purpose-specific judgment call whether or not these should be considered static type errors. If the purpose is to enforce a strict, Javalike programming style, they should probably all be considered errors. If, in contrast, the goal is ...

Peer-review is a valuable tool that helps both the reviewee, who receives feedback about his work, and the reviewer, who sees different potential solutions and improves her ability to critique work. In-flow peer-review (IFPR) is peer-review done while an assignment is in progress. Peer-review done during this time is likely to result in greater motivation for both reviewer and reviewee. This workinggroup report summarizes IFPR and discusses numerous dimensions of the process, each of which alleviates some problems while raising associated concerns. In-Flow Peer-ReviewPeer-review has been employed for various reasons in Computer Science courses [61]. It is a mechanism for having students read each others' work, learn how to give feedback, and even to help with assessment. Indeed, of the six major computational thinking skills listed in the current draft of the AP Computer Science Principles curriculum [13], the fourth is:P4: Analyzing problems and artifacts The results and artifacts of computation and the computational techniques and strategies that generate them can be understood both intrinsically for what they are as well as for what they produce. They can also be analyzed and evaluated by applying aesthetic, mathematical, pragmatic, and other criteria. Students in this course design and produce solutions, models, and artifacts, and they evaluate and analyze their own computational work as well as the computational work that others have produced.Students are expected to:• Evaluate a proposed solution to a problem;• Locate and correct errors;• Explain how an artifact functions; and • Justify appropriateness and correctness.Peer review clearly has a role to play in developing each of these skills. Students must read and evaluate proposed (partial) solutions, try to at least locate (if not offer corrections to) errors, offer their explanations for what an artifact is doing (especially if it does not match the expectations set by the problem), and justify their views on the appropriateness and correctness of presented solutions. Giving authors the ability to respond to reviews further reinforces the quoted principles.Peer review has uses beyond merely evaluating programs. Writing benefits from peer review (Topping's review lists several exampes [61, page 261]), as do other artifacts that aren't just programs, like design diagrams, test suites, formal models, documentation, and presentations. All of these artifacts are also fair game for peer review in computer science courses and more, and peer review addresses similar underlying learning goals of evaluation and explanation of existing work.This working group explored a particular variant of peer-review called in-flow peer review [47] (IFPR). In this model, peer review occurs while an assignment is in progress, before students submit their work for final grading. Performing peer-review in-flow has several potential benefits:• It helps students better understand the problem specification.If the work they see others doing is inconsistent with their understanding, one...