Iframe sandbox improvments - Revision history

Mkwst at 06:47, 16 July 2015

2015-07-16T06:47:43Z

← Older revision		Revision as of 06:47, 16 July 2015
Line 50:		Line 50:
	In none of the above cases would a dialog be presented to the user.		In none of the above cases would a dialog be presented to the user.

			== Bugs ==

			* Auxiliary: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28817
			* Modals: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28818
	[[Category:Proposals]]		[[Category:Proposals]]

Mkwst: Loosen the auxiliary proposal to 'allow-popups-to-escape-sandbox'.

2015-07-06T09:38:51Z

Loosen the auxiliary proposal to 'allow-popups-to-escape-sandbox'.

← Older revision		Revision as of 09:38, 6 July 2015
Line 26:		Line 26:
	This proposal adds '''a <em>sandbox propagates to auxiliary browsing contexts</em> flag''' to the sandboxing flag set defined in https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set.		This proposal adds '''a <em>sandbox propagates to auxiliary browsing contexts</em> flag''' to the sandboxing flag set defined in https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set.

	This flag is set when parsing a sandboxing directive, unless the <code><strong>allow-~~unsandboxed~~-~~auxiliary~~</strong></code> keyword is present.		This flag is set when parsing a sandboxing directive, unless the <code><strong>allow-popups-to-escape-sandbox</strong></code> keyword is present.

	If the flag is present when opening a new auxiliary browsing context (for example, via <code>window.open</code> or <code>target="_blank"</code>, then:		If the flag is present when opening a new auxiliary browsing context (for example, via <code>window.open</code> or <code>target="_blank"</code>), then the new browsing context's [https://html.spec.whatwg.org/multipage/browsers.html#popup-sandboxing-flag-set popup sandboxing flag set] will not inherit the opener browsing context's active document's active sandboxing flag set (in [https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name step 5 of the "rules for choosing a browsing context given a browsing context name"]).

	~~# The~~ new browsing context's sandboxing flag set will not ~~be populated from~~ the ~~opening~~ document's active sandboxing flag set.
	~~# The newly created browsing context will~~ [https://html.spec.whatwg.org/multipage/browsers.html#~~disowned~~-~~its~~-~~opener disown its opener].~~

	~~Further, if <code>window.open</code> is used to open the new~~ browsing context:

	~~# The <code>~~name~~</code> argument to <code>window.open</code> is always interpreted as <code>_blank</code>.~~
	~~# <code>window.open</code> will continue to return <code>null</code> in~~ the ~~case in which the new window's creation is blocked (via~~ a ~~popup blocker, for instance~~)
	~~# <code>window.open</code> will return <code>true</code> if a window is successfully opened~~.

	=== Modal Dialogs ===		=== Modal Dialogs ===

Mkwst at 11:48, 23 June 2015

2015-06-23T11:48:59Z

← Older revision		Revision as of 11:48, 23 June 2015
Line 35:		Line 35:
	Further, if <code>window.open</code> is used to open the new browsing context:		Further, if <code>window.open</code> is used to open the new browsing context:

			# The <code>name</code> argument to <code>window.open</code> is always interpreted as <code>_blank</code>.
	# <code>window.open</code> will continue to return <code>null</code> in the case in which the new window's creation is blocked (via a popup blocker, for instance)		# <code>window.open</code> will continue to return <code>null</code> in the case in which the new window's creation is blocked (via a popup blocker, for instance)
	# <code>window.open</code> will return <code>true</code> if a window is successfully opened.		# <code>window.open</code> will return <code>true</code> if a window is successfully opened.

Mkwst at 08:57, 23 June 2015

2015-06-23T08:57:17Z

← Older revision		Revision as of 08:57, 23 June 2015
Line 1:		Line 1:
	This is a ~~test~~.		== Overview ==

			This document proposes two behavioral changes for sandboxed <code><iframe></code> elements, each governed by a new sandboxing keyword.

			== Use Case ==

			Folks who embed third-party widgets via <code><iframe></code> elements are often interested in reducing the privilege of those embedded documents in various ways in order to protect themselves and their users from those with malicious intent. The <code>sandbox</code> attribute is a natural fit here, as it prevents embedded-but-untrusted content from acting in a number of ways counter to the embedder's intent.

			=== Auxiliary Windows ===

			Advertisers, in particular, deal with large amounts of untrusted code, and would be interested in sandboxing third-party content in order to prevent things like top-level navigation from an <code><iframe></code> and access to <code>document.cookie</code> and similar storage APIs. <code>sandbox</code> gives them this capability, but ties it to other restrictions that they can't accept.

			The most critical of these restrictions is the fact that sandboxing flags "inherit" out to new windows created from within the sandboxed frame. This is, of course, an important part of the sandbox: if new windows could easily escape
			the sandbox's restrictions, they'd be fairly trivially bypassed. It makes sandboxing unusable for ads, however, because the advertised landing page can't (and shouldn't) be sandboxed in the same way as the embedded advertisement. While it might be reasonable to prevent the advertisement from accessing storage mechanisms, it would be fairly devastating to impose the same restrictions on the page being advertised.

			=== Modal Dialogs ===

			Dialog windows popped up in response to JavaScript methods like <code>alert()</code> and <code>prompt()</code> are sometimes difficult for a user to contextualize. Malicious third-parties intentionally use these kinds of mechanisms in order to create confusion, and convince users to take actions against their best interests.

			<code>sandbox</code> doesn't currently allow an embedder to protect themselves from this kind of abuse. Again, folks combating malicious advertisement would benefit from a mechanism which provided this functionality.

			== Proposal ==

			=== Auxiliary Windows ===

			This proposal adds '''a <em>sandbox propagates to auxiliary browsing contexts</em> flag''' to the sandboxing flag set defined in https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set.

			This flag is set when parsing a sandboxing directive, unless the <code><strong>allow-unsandboxed-auxiliary</strong></code> keyword is present.

			If the flag is present when opening a new auxiliary browsing context (for example, via <code>window.open</code> or <code>target="_blank"</code>, then:

			# The new browsing context's sandboxing flag set will not be populated from the opening document's active sandboxing flag set.
			# The newly created browsing context will [https://html.spec.whatwg.org/multipage/browsers.html#disowned-its-opener disown its opener].

			Further, if <code>window.open</code> is used to open the new browsing context:

			# <code>window.open</code> will continue to return <code>null</code> in the case in which the new window's creation is blocked (via a popup blocker, for instance)
			# <code>window.open</code> will return <code>true</code> if a window is successfully opened.

			=== Modal Dialogs ===

			This proposal adds '''a <em>sandboxed modals</em> flag''' to the sandboxing flag set defined
			in https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set.

			This flag is set when parsing a sandboxing directive, unless the <code><strong>allow-modals</strong></code> keyword is present.

			If the flag is set, <code>alert()</code>, <code>confirm()</code>, <code>prompt()</code>, and <code>print()</code> will be neutered inside of a sandboxed IFrame in the following ways:

			# <code>alert()</code> would be equivalent to calling <code>function () { return undefined; }</code>.
			# <code>confirm()</code> would be equivalent to calling <code>function () { return false; }</code>.
			# <code>prompt()</code> would be equivalent to calling <code>function () { return null; }</code>.
			# <code>print()</code> would be equivalent to calling <code>function () { return undefined; }</code>.

			Further, if the flag is set, <code>beforeunload</code> event handlers for the framed Document are neutered in the following way:

			# Step 8 of [https://html.spec.whatwg.org/multipage/browsers.html#prompt-to-unload-a-document the "prompt to unload a document" algorithm] will not prompt the the user to confirm that they wish to unload the framed document, but will instead act as though the user confirmed the page navigation.

			In none of the above cases would a dialog be presented to the user.

	[[Category:Proposals]]		[[Category:Proposals]]

Mkwst: added Category:Proposals using HotCat

2015-06-23T08:08:14Z

added Category:Proposals using HotCat

← Older revision		Revision as of 08:08, 23 June 2015
Line 1:		Line 1:
	This is a test.		This is a test.

			[[Category:Proposals]]

Mkwst: This document proposes two behavioral changes for sandboxed iframes, each governed by a new sandboxing keyword.

2015-06-23T08:07:41Z

This document proposes two behavioral changes for sandboxed iframes, each governed by a new sandboxing keyword.

New page

This is a test.