Saarland University Logo Computer Science Logo Cornell Computer Science Logo

f-unit in the SAFE activation framework







ramework for



We present a novel method for enabling fast development and easy customization of interactive data-intensive web applications. Our approach is based on a high-level hierarchical data-centric programming model that results in a very clean semantics of the application while, at the same time, it provides well-defined interfaces for customization of application components.

SAFE at a glance

SAFE comes with the following features:


More and more software is delivered through the web, following today's cloud idea of delivering Software as a Service (SaaS). The code of such rich internet applications (RIAs) is split into client and server code, where the server code is run at the service provider and the client accesses the application through a web browser. In data-driven web applications, the state of the application resides in a database system (or in a key-value store), and users interact with this persistent state through web clients. In this project, we propose

a framework for personalizing


data-driven web applications

. By personalization we mean that a user has the capability of customizing the functionality of an RIA to fit her unique application needs.

As a first example

, consider Facebook user Mark, who no longer likes a single news feed for all of his contacts; Mark wants to split the news feed into two columns, one for his friends and one for his business contacts. Today, Mark would have to wait (and hope) for Facebook to create this functionality as part of an upgrade of its interface. We envision a world where Mark could take the initiative himself; he could directly "program" this extension and integrate it for himself into the running Facebook application. Mark could also provide this extension as an "App" to other users who desire the same functionality. Note that this is not a "Facebook Application" as enabled by the Facebook API, but it is a customization of the core user-facing Facebook functionality through a user-defined extension.

As a second example

, consider a conference management system such as Microsoft's Conference Management Tool (CMT). From time to time, the team behind CMT introduces a new feature that has been long requested by the community (see, for example, the features currently marked "(new!)" on the CMT website). None of these extensions is difficult to build, but today any changes are only within the realm of the CMT developers. In addition, due to limited resources, the team only incorporates extensions requested by the majority of users and thus forgoes the opportunity to serve the long tail. For example, consider Surajit who wants to run his conference with shepherding of borderline papers. Currently, Surajit has to wait and hope that the CMT team considers his functionality important enough to release it as part of its next upgrade. However,

we believe that innovation and integration of


new functionality can be significantly increased

if Surajit could directly take initiative, program the extension himself, and then share it with others in the research community who desire similar functionality. Thus

we want custom extensions to be built by any member of the community

instead of being left only to the CMT team.
In both of these examples,

personalization of an existing data-driven web application by a third party

who was not the developer of the original application is the key to success. Note that personalization not only benefits the user who programmed it; an extension could later on be shared with other users, making the application automatically an "extension app store" where users can (1) run the RIA directly as provided, (2) personalize it with any set of extensions developed and provided by the community, (3) personalize it themselves through easy and well-defined user interfaces, and then (4) share or sell their extensions to the community.

The tremendous benefits of personalization also come with huge challenges. First, the often organic growth of today's RIAs makes it hard to keep track of the diversity of locations to which code has to be integrated, thereby obeying various security and safety constraints regarding, for instance, namespaces and assertions. This dispersion of code "all over the place", which is exacerbated by the integration of different programming models and languages for the client and server, makes it hard to bundle functionality for replacement through personalization. But since developers cannot anticipate all possible ways of extending an application,

how do we design a web application such that future extensions are easy to integrate?

Second, the code of the extensions will have to be activated, it may have to pass data back and forth with other application components, and it requires access to the state of the application in the database.

How do we address the security concerns of integrating such untrusted code into a running web application?


The Safe Activation Framework for Extensibility is a novel framework for the design of data-driven web applications tailored to user-provided customization. Let us give a brief overview of SAFE and its features.

Design for Personalization.

SAFE structures data-driven web applications into a hierarchical programming model inspired by Hilda. Functionality is clustered into so-called f-units that contain all the relevant code to implement a component of the application. The control flow of the application has a clean hierarchical semantics: An f-unit is activated by its parent f-unit and becomes its child resulting in a tree of activated f-units. This so-called activation tree naturally corresponds to the hierarchical DOM structure of an HTML page. There are two well-defined points of information flow for an f-unit: Its activation call, through which the f-unit was activated by its parent f-unit, and queries to the database where the state of the application is stored. Thus a user who would like to personalize an application simply has to replace an existing f-unit with a new f-unit of her choice or design. Such customizations are dynamic in that f-units are registered and activated without stopping the running system. These dynamic software updates (DSU) avoid costly unavailabilities of the running system. SAFE has a security model that is tailored towards the integration of untrusted code by splitting the code of an f-unit automatically between client and server. Database queries specified by a programmer will never appear in the client code, sanitization of query values to prevent SQL injection attacks automatically occurs on the server, and event handlers for asynchronous update request end up in the client. SAFE also contains a reference monitor which takes care of all low-level details such as secure registration of f-units, access control, and verification of user actions and requests received from the client. Note that even only achieving modularity when designing data-driven web applications is nearly impossible. The f-units in SAFE can be thought of as classes in object-oriented programming. For web applications, however, there are several different languages (for example, HTML, PHP, Java, JavaScript, SQL, CSS) providing different data models for the different application layers (e.g., the relational model for databases, Java objects for the application logic, hyperlinks for website structure, and form variables for web pages). This variety makes it hard to achieve modularity since fragments of different languages are in different parts of the source tree. Usually, a single JavaScript command like


is not sufficient. Assume, as an example,


is responsible for displaying some


elements which are supposed to appear only two seconds after the main HTML page has been loaded. In this case, an event handler for


events of the document has to be modified accordingly. Typically, such an event handler is a named JavaScript function, referenced in the


tag of the main HTML page:

<body onload='pageLoaded()'>

. The JavaScript function


is uniquely declared at some other location, most likely in the


area of the HTML page. This declaration has to be updated if


needs some actions to be performed when the page has been loaded; some lines of JavaScript code have to be added to the body of the function. For a different language, for example for PHP, the integration of new functionality again is different. Another difficulty in the integration of new functionality is to ensure that namespaces of different pieces of code do not interfere. Assume that we have two code fragments




which each have an HTML element with id


and corresponding CSS specifications. A namespace concept would separate the CSS for


from the CSS of


, and we have to add this manually in order to resolve this conflict. As part of its hierarchical programming model, SAFE provides solutions to address all these problems.

Client-Server Consistency.

Modern interactive web applications give the user a feeling of locally executing a fully-fledged software binary by communicating with the server asynchronously. The typical way of implementing this is through client-side event-driven programming. One challenge when writing this client-side code is that the state of the application at the client can be different from the state at the server, since other clients simultaneously connect to the same application and may modify the state of the system at the server, for example when one user updates a data item that another user is currently displaying. To avoid such inconsistent updates, the programmer would have to manually include all kinds of consistency checks, which is error-prone and cumbersome. SAFE alleviates the developer from this burden by making consistency checks a first-class citizen in the model, providing an easy to use SQL-based declarative state monitoring interface that automatically derives the necessary checks. SAFE automatically compiles the developer code to safe state transitions which cleanly abstracts out concurrent updates into standard serialization semantics known from interacting with a database.

Ease of Development.

SAFE also includes many different mechanisms to minimizing the amount of low-level code that a developer has to write. (1) Programs in SAFE are written in SFW, a high-level programming language that abstracts away many low-level code fragments through appropriate high-level statements. For example, it is often cumbersome to specify explicit loops and to iterate over the objects of a particular data structure thereby struggling with implementation details like counters, pointers or break conditions of that particular loop. SFW contains high-level constructs for many of these commonly re-occurring patterns. (2) One of the design principles of SFW is that we did not invent a new language, but rather create a framework that encompasses existing languages Our framework provides the full expressiveness of languages like HTML, PHP, SQL, and Javascript, but allows for shorter, yet semantically precise shortcuts that significantly reduce the amount of code a developer has to write. (3) Note that application developers may have to know about other elements in the DOM tree in order to ensure that all elements have pairwise unique IDs, and other elements are correctly addressed, e.g., whether an element has the


property or the


property. SAFE's modularization fosters local understanding because it automatically ensures that IDs are unique and that the developer only needs to locally care about the elements of the corresponding f-unit. (4) Today a lot of similar event-driven code for asynchronous server requests has to be written. However, the code for the update of an exam grade in a course management system is not much different from the code of updating the matriculation number of a student. In the spirit of DRY (Don't Repeat Yourself), as in Ruby on Rails, SAFE requires the developer to specify information and code at most once. For example, the code for the initial rendering of an f-unit is also used later to provide partial updates of modified data. No complicated event handlers have to be specified to rebuild certain elements in the browser's DOM tree. Another feature to reduce the amount of hand-written code is the paradigm of convention over configuration: SAFE decreases the number of decisions a developer has to make by establishing useful conventions on parameters and names of variables.


Raphael M. Reischuk Michael Backes Johannes Gehrke
Raphael M. Reischuk Michael Backes Johannes Gehrke


SAFE Extensibility for Data-Driven Web Applications
Raphael M. Reischuk, Michael Backes, Johannes Gehrke.
WWW '12: Proceedings of the 21st International Conf. on World Wide Web.
Download: via ACM DL
Secure and Customizable Web Development in the SAFE Activation Framework (demo paper)
Raphael M. Reischuk, Florian Schröder, Johannes Gehrke.
CCS '13: Proceedings of the 20th ACM Conference on Computer and Communication Security.
Download: via ACM DL
Balancing Isolation and Sharing of Data in Third-Party Extensible App Ecosystems (short paper)
Florian Schröder, Raphael M. Reischuk, Johannes Gehrke.
ICWE '15: Proceedings of the 15th International Conf. on Web Engineering.
Download: via SpringerLink, long version
The official SAFE manual (draft)
Raphael M. Reischuk
Download: PDF