The rise of web platforms and their associated apps represents a new way of developing and deploying software. Sites such as Facebook and Yammer are no longer written by a single entity, but rather are freely extended by third-party developers offering competing features to users.
Allowing an app to access more user data allows developers to build more compelling products. It also opens the door to accidental or malicious breaches of user privacy. In the case of a website like Facebook, exposing access to a user's private messages would allow an external developer to build a search feature. Exciting! But, another developer can take advantage of this feature to build an app that mines private messages for credit card numbers, ad keywords, or other sensitive data.
If the only tool you have is a hammer, you tend to see every problem as a nail. Abraham Maslow. The Psychology of Science, 1966.
Frameworks such as Ruby on Rails, Django, etc. are geared towards building monolithic web sites. And, they are great for this! However, they are not designed for websites that integrate third-party code, and thus lack a good mechanism for building such multi-app platforms without sacrificing a user's security or an app's functionality. Compensating for the lack of a better framework, platforms built using such existing tools have addressed the trade-off between user privacy and app functionality by asking users to grant permissions to apps upon installation. There is little evidence this offers users any real protection in practice. Think of the number of times you (or your security-"unaware" friends) have installed an app because of the exciting features despite the questionable access it asked to be granted.
Hails is explicitly designed for building web platforms, where it is expected that a site will comprise many mutually-distrustful components written by a variety of entities. We built Hails around two core design principles.
To give you a clearer idea of the architecture of a Hails platform, consider an example platform that is similar to gitstar.com:
Such a platform hosts two types of code: apps (Code Viewer, Git-Blog, and Bookmark) and policy modules (GitStar and Follower). Apps encompass what would traditionally be considered controller and view logic. Policy modules are libraries that implement both the model and the data security policy. They are invoked directly by apps or other policy modules, but run with different privileges from the invoking code. Both apps and policy modules can be implemented by untrusted third parties, with the user only needing to trust the policy module governing the data in question.
Apps: At the heart of every Hails app is the Hails HTTP server, a privileged part of the trusted computing base (TCB). The server receives HTTP requests and invokes app controllers to process them. App controllers, in turn, call into policy modules in order to interact with persistent state. Finally, an invoked app returns a response, which the server returns to the browser on the condition that it depend only on data the user is permitted to observe. Language-level MAC prevents apps and policy modules from modifying or leaking data in violation of access permissions.
Policy modules: A policy module is a library with access to the privileges of a dedicated principal (conceptually, the author of the library) and associated with a dedicated database. The job of the policy module is to specify what sort of data may be stored in this database, and what access-control policies should be applied to it. However, because Hails uses MAC to enforce policies, a policy specified by a policy module on a piece of data is enforce even when an app gets a hold of the data.
MAC lets apps and policy modules productively use other policy modules despite mutual distrust. As an example, when a user views a repository on GitStar, a code viewer app formats file contents for the user. Were the app malicious, MAC would nonetheless prevent it from, say, displaying the contents of a private repository to users without access or transmitting repository contents to the app author. Hence the core GitStar app makes repository contents available to any app and users can safely chose third-party viewers based solely on the features they deliver rather than the trustworthiness of the app authors. These apps may, in fact, display data in completely different form. For instance, Git-Blog takes files stored in git and runs markdown on them. This app, implemented by a third-party developer (soon: you!), can provide the functionality of GitHub pages to extend the GitStar user experience. No longer will you have to be a developer on the core-platform team or wait for a feature request to extend a website!
cabal install hails