# The Content Vault The purpose of this document is to gather your comments about the feasibility of the idea of a Content Vault (CV). After gathering your comments, a more formal RFC will be drafted.
I’d like to use your comments to colour the proposal, from a platform, security and privacy perspective, and from others if needed. This is about a new Firefox feature that will allow access to privileged information in a content jail, that tries not to let information leak out. Another descriptive term for this is a privacy vault. The state within that vault may be changed, perhaps on a global or per-domain manner. This sandbox will allow the transformation of DOM elements prior to rendering, but unavailable to the parent page. The basic idea is to create a new kind of iframe, with special privileges and limitations. In some ways, this may be considered the opposite to HTML5 sandbox (http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes), whose focus is primarily on integrity; the focus of our solution is on confidentiality or privacy. The idea of the content vault was brought to me by Ben Livshits, a Research Scientist at Microsoft Research. Ben’s interests are broad, and include Security and Privacy. Ben wishes to be involved in this project; we will have his input on the matter. Ben can be found online: http://research.microsoft.com/en-us/um/people/livshits/ ## Rationale Today’s Internet user expects a great level of personalization. Websites achieve this personalization by building a relationship with that user, and sometimes through third parties. Those websites commonly create a profile for that user, append new data with each interaction and often enrich that corpus by buying additional data from brokers. The act of personalization is not inherently wrong and is often desired. User experiements show that personalization increases user engagement and satisfaction in the long run. We, after all, expect our computers to be useful devices and that involves a degree of personalization. However, the cost is often at the expense of privacy and/or security. With the idea of a content vault, we may be able to achieve some level of personalization while keeping the data within the control of the user agent, thus preventing data leaks. ## The Content Vault This vault would: • not be accessible from the parent page (similar to x-domain iframes) • have limited capabilities (e.g. no network access) • have access to privileged data stored in the UA • do decisioning in UA without leaking externally • expose an API only accessible inside a sandbox (e.g. declaratively allow for certain lists of items to be re-ordered) ### Privileged Data At this point, the data the CV has access to is not that relevant. For illustration purposes, here are some examples of data that would show the sensitive nature and utility of such data: • product purchase history • content preferences (e.g. +ve or -ve signals for topics) • absence or presence of signals gathered on the internet This pieces of data could inform the rendering of the contents of the CV, in a way that keeps the data within the UA. This data would not be otherwise accessible. ### Vault limitations The CV would have limited capabilities. For instance, certain API endpoints will be closed off, e.g. XHR. The idea is to make it so that the runtime for this content to be completely self-contained, aside from the rendering to the user. The vault would only be allowed to do transformations to the DOM content and perhaps to modify state within the UA that is only accessible via another vault. Along the same vein as CSP, resources and capabilities for the CV could be declared ahead of time. To mitigate information leakage, for instance, resources could be required to be declared in advance. Those resources would be loaded and perhaps pre-rendered prior to being selected and drawn. ### Vault API To aid in personalizing content, an API will be made available within the vault. This API will only be made available within the CV and may declare certain domain permissions. An example of a potential declarative API: <ul personalizable=”true”> <li topic=”business”>...</li> <li topic=”baseball”>...</li> <li topic=”foobarwidget”>...</li> </ul> This could trigger the UA to re-order based on users’ preferences, most preferred on top, and blacklisted topics hidden. The goal of the surrounding CV is to prevent nosy JavaScript from discerning the user’s preferences from the DOM state. JavaScript API’s could also be offered. ## Application ### Inline The CV could be used embedded in pages, or in what is considered browser chrome. An example ### Tiles It could be used to implement the idea of “Dynamic Tiles” in Firefox (an idea coming from Doug Turner’s team). Those tiles would be defined as page fragments and potentially scripts obtained from the internet. They’d show up in the newtab page if a page frecent enough is present. ### Mobile Applications From the perspective of the web as a platform, there needs to be protection between applications potentially present in the same UI. A direct application of this would be mobile apps containing other mobile apps. For instance, an app could provide a way for a user to manipulate a contact list without having access to all of it. ## The Asks I’d like you to comment on: • Feasibility of the vault at the platform level • requiring a separate JS runtime • blocking certain APIs • access to a data store for privileged data • Potential Security / Privacy leaks • Have to watch out for timing attacks • Unintended data leak, e.g. a:visited CSS issue • What are acceptable data leaks? • What are inacceptable data leaks? • WebAPI feasibility • CV DOM declarative syntax • CSP-style script and resource declaration • Performance implications • no lazy rendering • pre-loading/pre-rendering of assets ## Additional comments <mconnor> it's an iframe with special powers <mconnor> how we decide if that iframe gets those powers matters <mconnor> how we sandbox them from each other matters <mconnor> how do we keep that data in the sandbox <mconnor> it's interesting, but it's also terrifying :) - Olivier +1 (647) 299-6074 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
