Re: Content Vault Feasibility RFC
Hi all, We are still working on COWL on two fronts. First, I am currently drafting up the FPWD for COWL. Second, we also started thinking about COWL in the context of extensions, which I ma share some similarities with the proposed CV. A draft position paper of this is available [1], but we also started hacking on this---would be happy to share more details and see if there are commonalities. From the description below, I think that COWL's confinement can be used to get some of the desired properties. In particular, if you create an iframe whose label is a unique origin---but don't give it the privilege for this origin (hence different from HTML5 iframe sandbox)---then the code in the iframe can effectively only manipulate the DOM. (This was the idea behind the fresh privileges.) COWL adds more restrictions on top of SOP and CSP, so we don't expose any APIs for accessing more privileged data, but I can't tell from your description if this is actually something that you want to do. Ben: are there particular things that you have in mind that COWL doesn't address? Best, Deian [1] http://www.scs.stanford.edu/~deian/pubs/heule:2015:the-most.pdf Ben Livshits writes: > Looking forward to hearing more from Deian! I wonder if Bobby means the COWL > paper. Best. > > -Ben > Sent from a mobile device > > On Feb 3, 2015, at 10:40, Bobby Holley > mailto:bobbyhol...@gmail.com>> wrote: > > Looping in Deian, who was working (is working?) on something like this. > > On Tue, Feb 3, 2015 at 9:35 AM, Monica Chew > mailto: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 > mailto: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. >> >> ## T
Re: Content Vault Feasibility RFC
Looking forward to hearing more from Deian! I wonder if Bobby means the COWL paper. Best. -Ben Sent from a mobile device On Feb 3, 2015, at 10:40, Bobby Holley mailto:bobbyhol...@gmail.com>> wrote: Looping in Deian, who was working (is working?) on something like this. On Tue, Feb 3, 2015 at 9:35 AM, Monica Chew mailto: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 mailto: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
Re: Content Vault Feasibility RFC
On Tue, Feb 3, 2015 at 3:45 PM, Ben Livshits wrote: > Looking forward to hearing more from Deian! I wonder if Bobby means the > COWL paper. Best. > Yes. There was ongoing research after the COWL paper by the Stanford team. The last time I spoke with them about it was in August, so I don't know what the current status is. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Content Vault Feasibility RFC
Hi Monica, Thanks for your comments. We've been thinking about this for a while. Yes, we are very familiar with this work, but the setting is a little different. In RePriv, for example, we had to analyze the personalization code which is fine for research idea but won't work so well in practice. Fundamentally, the challenge is that malicious active content can leak the results of personalization, possibly to third parties. How much of an issue that is, we can certainly debate, but this is the reason we're trying to figure out how to use runtime enforcement to create such a privacy vault. The ad-focused efforts often solve these challenges through some form of multiplexing batches of ads, which is sort of difficult for arbitrary HTML content... Thanks, Ben From: Monica Chew Sent: Tuesday, February 3, 2015 9:35 AM To: Olivier Yiptong Cc: dev-platform; Sid Stamm; Marcos Caceres; Ehsan Akhgari; Christoph Kerschbaumer; Ed Lee; Ben Livshits Subject: Re: Content Vault Feasibility RFC 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 mailto: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: •
Re: Content Vault Feasibility RFC
Looping in Deian, who was working (is working?) on something like this. On Tue, Feb 3, 2015 at 9:35 AM, Monica Chew 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 > 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
Re: Content Vault Feasibility RFC
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 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 perh
Re: Content Vault Feasibility RFC
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 > 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. We
Re: Content Vault Feasibility RFC
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 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
