Culture

A secure and private browser sandbox

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.

Categories: Culture

Tagged as: , ,

6 replies »

    • It seems like a nice product, but it’s not implemented the sandboxes like I propose. Not to denigrate the product, but this seems akin to using something like Firefox with a lot of privacy plugins installed.

      It doesn’t seem to be getting at the heart of the issue. All this extra blocking does make sense, but only once the core of the experience is more private and secure.

    • I haven’t gotten the chance to even test it. The made it for Windows and Mac..like…what? I wish they had a Linux build. I totally know what you mean though. Just yesterday, I was talking with my sister, and she sent a link to a dress, without even clicking it I got the ad on Facebook for the website.

    • From the description provided there it sounds like one more ad-hoc measure. A confinement system for JavaScript that controls what is read and not read. It still sounds like data is being shared between domains.

      Perhaps it has some value in addition to the sandbox system, but on its own I don’t see how it will solve the problem.

  1. Research papers are available at: http://cowl.ws/ and the code should be there on 15th this month, too.

    But I think you’re right. It seems to make connections more secure such as in the Google Docs/EFF example, but I haven’t seen much about stopping cross-site tracking. It seems unlikely Google would fund or work on such a project anyway.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s