- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Mon, 27 Feb 2012 15:52:04 -0800
- To: David Bruant <bruant.d@gmail.com>
- CC: Jacob Rossi <Jacob.Rossi@microsoft.com>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 2/25/12 12:44 PM, David Bruant wrote: > I think that this is annoying. I understand the necessity of isolating > the scripts running in a frame from scripts running in other frames, but > I don't see why this would be done at the cost of features (especially > local storage which has no replacement) Either you trust those scripts or you don't. If you don't they might be stealing confidential data from localstorage or they might be injecting data that leads to DOMXSS or other security bugs. The best we could do safely is allow sandboxed content to access an anonymous temporary form of storage. If you trust the content then don't sandbox; if you distrust it then sandbox and you'll have to set up a postMessage() gateway to pass sanitized information back and forth. > Also, if someone really wants a sandboxed page, why not serve the > document as html-sandboxed? I mean add support for this content-type at > the browser level (as opposed to only iframe level) That would be easy to implement if you're already supporting it for iframes. If that's a valid content-type but only for iframes then what are browsers supposed to do if they get it as a top-level document? I think the only safe choices are to support that type sandboxed or refuse to load the document at all. -Dan Veditz
Received on Monday, 27 February 2012 23:52:47 UTC