A patchwork set of standards and rules is creating an unsafe web. Cross-site attacks are too common and privacy leaks have become the norm. There’s no reason it has to be like this. In this article I propose a sandbox approach as a base to a better model.
Domain sandbox
Currently a web page can share data across many domains. The domain of each script, or resources, gets to access global data related to that domain. And these scripts can communicate with each other on the page to share that data. This means the page, as a whole, is using a browser-wide shared data pool. It allows a domain, like google.com, to both persist and use data across all the pages you visit on any site, as well as gain access to that large shared pool of data.
I’d like to see this data isolated. The domain I see in the URL bar should be a sandbox. Everything included within that page is segregated into this exclusive data space. This includes everything from cookies and local storage to cache, and history. The set of data available to this sandbox is entirely limited to data generated while at that domain.
Resources can still be included from a variety of domains, but the data they use is exclusive to this sandbox. A script from google.com on youtube.com would be completely isolated from the same script running at blogger.com.
This model solves a couple of key issues for security and privacy. It prevents cross-site request forgery. Authorizing a service, like Facebook, would be limited to the sandbox in which the authorization was done. When you go to some other random site, it’s like you’ve never been to Facebook before. An attacker could contact facebook.com, but it’ll just be rejected since Facebook won’t know who you are.
It prevents global user tracking. It is more difficult for tracking networks, like Google Analytics, to build a single user profile. Their servers are unable to create the single shared cookie that identifies you. Indeed, every domain will look like a new user to Google. Unlike disabling JavaScript the sandbox does not block helpful user experience tracking on an individual site.
It also helps ensure privacy on maligned domains. There is no way a page can glean information about what you do on other domains. No CSS nor JS trick can somehow reveal what domains you’ve visited, or anything about what you’ve done in those other sandboxes.
Remote resource permissions
I don’t want to break the practice of using third-party services in web pages. When used effectively these can significantly improve user experience and reduce development time. These third-party services should however be contained. They shouldn’t be given free reign over the browser as they are today.
Third party scripts, identified by their domain, should again go in a sandbox. This sandbox is a child of the primary domain. So a request to chartbeat.com from youtube.com will be a in separate sandbox than a request to chartbeat.com from linkedin.com.
The purpose of this sandbox is to give the primary domain complete control over what the third party sandbox can access. By default it can only access the third-party sandbox. If the service needs access to the URL of the current page, it will be listed in a set of permissions. If it’s allowed to modify the DOM, it must also be listed.
Note the default permissions for a third-party domain won’t even allow scripts from that domain to be loaded. The primary domain must explicitly list the domains it uses and which permissions they have. This greatly limits the effectiveness of cross-site scripting since the attack would find itself trapped.
I’m uncertain on exactly how the permissions should be specified. Either in the HTTP headers or as a specific endpoint on the primary domain (using an OPTIONS request).
In no way can a permission ever violate the primary sandbox. These permissions are only for the parent-child sandbox relationship. The primary sandboxes are invariably isolated.
DOM Permissions
For scripts that modify the DOM the security should also control what part of the DOM that can be modified. By default a script cannot modify the DOM at all, but giving full DOM access also isn’t safe.
The permissions for DOM should allow restricting to the children of a particular element. If a page says someservice.xx may modify the DOM, by default this is limited to the node where the <script> element appears. Additional nodes can be specified by providing their id in the permissions list.
User Control
In addition to security, the sandboxes and permission lists give the user a greater degree of control and knowledge. The primary domain sandbox can be clearly identified in the browser. An option is also available to list the third-party services in use on a particular page.
A browser can offer options for the persistence of the sandbox. Instead of just holding all data forever, the user could mark a domain as being deleted after a few weeks, or deleted immediately after completion (much like the private browsing modes do). This allows the user to properly discard all sensitive data from their online banking, yet allow long-term storage for their favourite games site.
It also gives a clean way for a user to blacklist services and limit permissions. Like mobile devices ask the user for permission, so could the browser. A user may decide they don’t like Google getting any data and thus blacklist Google Analytics from all pages.
Adoption
The primary sandbox can be implemented without any kind of support from major websites. All sites have to support new users and new browser installs already, so they will work fine in a sandbox. Any browser vendor could implement this right now. I imagine this to be a major selling point to many users.
The permission system doesn’t strictly require the support of the service providers. This is actually the intent: the security model is not optional. A well behaved service fits fine within this new model; it should be straight-forward to define a simple set of permissions required by such services. Misbehaved services will have troubles in this model, and that is exactly what we want. It’s the pressure system used to force service providers to create better services.
Using third-party services actually becomes easier in this model. Instead of fighting with a bunch of ad hoc third-party rules and the nonsensical CORS standard, a web page is now free to use the web as it was intended. A developer can use whatever services they want, they just need to specify the permissions.
I would gladly switch to a browser that offers the sandbox model.
I’m a software developer with experience in many fields, from engineering to media, from finance to games. I believe our users are entitled to high quality software and I strive to deliver it. Please contact me about working on your project, or if you’d like a talk about one of my articles.
