Looping in Deian, who was working (is working?) on something like this. On Tue, Feb 3, 2015 at 9:35 AM, Monica Chew <m...@mozilla.com> wrote:
> Hi Olivier, > > I agree with ekr and Richard. There has been a lot of research lately about > how to do personalization in a privacy-preserving manner. > > Bloom Cookies: Web Search Personalization without User Tracking, NDSS 2015 > http://research.microsoft.com/pubs/238114/BloomCookies.pdf > > RePriv: Re-Imagining Content Personalization and In-Browser Privacy, S&P > 2011 (Livshits is a co-author on this one) > > http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/oakland11.pdf > > Privad: Practical Privacy in Online Advertising, NSDI 2011 > http://static.usenix.org/event/nsdi11/tech/full_papers/Guha.pdf > > Adnostic: Privacy Preserving Targeted Advertising, NDSS 2010 > http://crypto.stanford.edu/adnostic/ > > None of these require what is essentially the equivalent of limited XSS on > behalf of ad networks. Have you evaluated if these work for you? > > Thanks, > Monica > > 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
