Features/Platform/Iframe Sandbox: Difference between revisions

* The origin (in string form) of a null principal - this will be sent by CORS, the origin header (if/when it's implemented), postMessage etc - the HTML5 spec says that it should be a GUID in this case - need to see what gets used in these cases when content has a null principal

* sandboxed IFRAME's should not be able to create popups, even with the 'allow-scripts' modified specified - need to figure out how to implement this block

|Feature overview=The HTML5 standard specifies a new attribute for the IFRAME element, "sandbox". See also [https://bugzilla.mozilla.org/show_bug.cgi?id=341604 bug 341604] "Implement HTML5 sandbox attribute for IFRAMEs" and [https://bugzilla.mozilla.org/show_bug.cgi?id=671389 bug 671389] "Implement CSP sandbox directive"

|Feature users and use cases=Users are web developers looking for a way to isolate content on their site and preventing it from having its default same origin privileges. The HTML5 spec specifies some modifying attributes that can re-grant permissions such as executing scripts and submitting forms, etc.

* We will use nsDocShell::SetAllowPlugins(false) to prevent plugins being loaded by a sandboxed IFRAME

* We will create the flags as described in the HTML5 spec's description of the IFRAME sandbox attribute on both the docshell and the document when it is loaded  

** when the sandbox attribute on an IFRAME element is modified, we will change the flags on the docshell but not the document  

*** we will try to implement this using nsGenericHTMLFrameElement::BeforeSetAttr/AfterSetAttr, propagating changes to the iframe's docshell via mFrameLoader->GetExistingDocShell()