It would be helpful if you could comment more on the use cases here. It's not entirely clear to me what's motivating this proposal. In your message, the "Inline" use case seems to have been truncated, and the "Mobile Applications" use case seems perfectly well addressed by iframes.
Let's focus on the "Dynamic Tiles" case. As I understand it, the proposal here is to have a piece of content that is displayed differently based on private information (e.g., a user's preference ordering). Given that, it seems like what you're asking for is a black box into which the untrusted content can write a request saying, "please customize this and render it without letting me see it". The problem with this is that the black box needs to be really black. Nothing externally observable about it can change, and it cannot be allowed to emit any information itself. As EKR points out, this is really, really hard. Even if you load everything into a sandbox with no network connectivity, JS can still exfiltrate secrets to other JS on the box, by doing things like running the CPU. In other words, the only possible safe way to inject private information into a page is if there is no dynamism in the page at all -- you just hand the resources to the browser and say "render as you please". In other words, given that that sounds pretty far from what you're asking for, I agree with EKR that this idea is unlikely to be workable. --Richard On Tuesday, February 3, 2015 at 11:29:37 AM UTC-5, Eric Rescorla wrote: > This kind of feature comes up frequently, but to the best of my knowledge > (which > I believe is fairly up to date) it is not known how to build a robust > version of this. > > To generalize the problem a bit, we have two pieces of software running on > the > user's computer: > > A: A confined process running in some sandbox but which has access to > some secret information. > B: A non-confined process running on the same machine but without access > to the secret information. > > Both of these processes are attacker controlled and presumed malicious. The > attacker's job is to exfiltrate the secret information from A to B. > > You'll note that when phrased this way we're back to the classic confinement > problems and MLS (see, for instance Lampson's "A Note on the Confinement > Problem). What makes this so difficult is that even if you close *all* the > explicit > channels between the two processes, we have to contend with covert channels > of which the browser has many. > > It's worth noting that we have at best partial solutions in two rather > easier settings: > > - We regularly have to content with cross-origin leakage situations in the > browser > even when the two sides are *not* cooperating, for instance CSS history > sniffing [1] > > - Multitenanted processes when: (a) you have much tighter system control > (b) the processes aren't cooperating (see, for instance, Ristenpart et > al. from > 2009 [0]). > > Given this and the generally low entropy of the data which needs to be > exfiltrated > in these settings, I'm not very enthusiastic about the prospects of this > working. > > -Ekr > > [0] > https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/ > [1] http://cseweb.ucsd.edu/~hovav/papers/rtss09.html > > > > On Tue, Feb 3, 2015 at 7:44 AM, Olivier Yiptong <oyipt...@mozilla.com> > wrote: > > > # 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 > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
