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 glanceSAFE comes with the following features:
- customization of functionality through safe extensibility
resulting in completely personalized web applications
- clustering of functionality
in f-units providing namespaces and bundles for all tiers: HTML/CSS/JS/PHP/SQLnecessary to achieve modularity for customization
- hierarchical data-centric programming model
which naturally builds upon the hierarchical DOM structure of web pages
and naturally meets the data-centric nature of web applications
- activation of f-funits via well-defined message flows
through well-specified interfaces
- automatic data updates with enforced state consistency
no inconsistent statesasynchronous communication for better performance
- prevention of code injection
through automatic client input sanitization,
hence no XSS attacks, no SQL injection
- access control for individual database columns
through runtime reference monitor
- several syntactically useful abstractions
through declarative modeling language SFW
- no browser plugins necessary at the client side
SAFE code runs in all major browsers without local adjustments
- compilation of declarative high-level specifications
resulting in secure web application modules
instead of analyzing arbitrary (and potentially undecidable) user-specified code
MotivationMore 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 personalizingsuch
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 ofsuch
new functionality can be significantly increasedif 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 communityinstead of being left only to the CMT team.
personalization of an existing data-driven web application by a third partywho 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?
SAFEThe 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.
include('moduleA')is not sufficient. Assume, as an example,
moduleAis responsible for displaying some
<div>elements which are supposed to appear only two seconds after the main HTML page has been loaded. In this case, an event handler for
<body>tag of the main HTML page:
pageLoaded()is uniquely declared at some other location, most likely in the
<head>area of the HTML page. This declaration has to be updated if
Bwhich each have an HTML element with id
studentListand corresponding CSS specifications. A namespace concept would separate the CSS for
Afrom the CSS of
B, 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.
innerHTMLproperty or the
valueproperty. 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|
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