Links to Unrelated Browsing Contexts - Revision history

Creis at 22:06, 18 June 2012

2012-06-18T22:06:32Z

← Older revision		Revision as of 22:06, 18 June 2012
Line 5:		Line 5:

	=== Current Limitations ===		=== Current Limitations ===
	There is currently no adequate way for such web apps to express that a link should be opened in an unrelated browsing context, with no <code>window.opener</code> or other script ~~connections~~ to the web app.		There is currently no adequate way for such web apps to express that a link should be opened in an unrelated browsing context, with no <code>window.opener</code> or other immediate script references to the web app.

	=== Current Usage and Workarounds ===		=== Current Usage and Workarounds ===
Line 16:		Line 16:
	=== Benefits ===		=== Benefits ===
	Having explicit syntax for this use case would allow browsers to open links in an unrelated browsing context, while still passing the Referer header. This would mean that the original page would not receive a reference to the new window, and the new window would have a null <code>opener</code>. Multi-process browsers could also decide to use a separate renderer process for the new page, allowing it to render concurrently and fail independently.		Having explicit syntax for this use case would allow browsers to open links in an unrelated browsing context, while still passing the Referer header. This would mean that the original page would not receive a reference to the new window, and the new window would have a null <code>opener</code>. Multi-process browsers could also decide to use a separate renderer process for the new page, allowing it to render concurrently and fail independently.

			Note that unrelated browsing contexts might still be able to discover each other if they have named windows. Most single-process browsers allow any named window to be found, and multi-process browsers like Chrome may allow named windows to be found if they are in the same renderer process. Entirely preventing a named window from being discovered is beyond the scope of this proposal.

	=== Requests for this Feature ===		=== Requests for this Feature ===
Line 23:		Line 25:

	=== 1. "Unrelated" Link Type ===		=== 1. "Unrelated" Link Type ===
	The proposed behavior would cause a link to open in a new, unnamed browsing context with a null <code>window.opener</code>, and with no reference to the new window ~~available~~ to the creator browsing context. Thus, the creator and new windows would be in different "units of related browsing contexts" (http://dev.w3.org/html5/spec/single-page.html#unit-of-related-browsing-contexts). There are two changes needed to support this: adding a link type for <code>"unrelated"</code> and providing a way to request this behavior with <code>window.open</code>.		The proposed behavior would cause a link to open in a new, unnamed browsing context with a null <code>window.opener</code>, and with no reference to the new window returned to the creator browsing context. Thus, the creator and new windows would be in different "units of related browsing contexts" (http://dev.w3.org/html5/spec/single-page.html#unit-of-related-browsing-contexts). There are two changes needed to support this: adding a link type for <code>"unrelated"</code> and providing a way to request this behavior with <code>window.open</code>.

	==== Processing Model ====		==== Processing Model ====
Line 43:		Line 45:
	==== Limitations ====		==== Limitations ====
	One issue with this approach is that http://dev.w3.org/html5/spec/single-page.html#dom-open says that the "features" argument of <code>window.open</code> should be ignored. However, supporting this type of additional behavior on <code>window.open</code> could be worth pursuing, since it could be useful for other link types (e.g., <code>"noreferrer"</code>) as well.		One issue with this approach is that http://dev.w3.org/html5/spec/single-page.html#dom-open says that the "features" argument of <code>window.open</code> should be ignored. However, supporting this type of additional behavior on <code>window.open</code> could be worth pursuing, since it could be useful for other link types (e.g., <code>"noreferrer"</code>) as well.

			Also, as noted above, if either window is named, it is possible that other unrelated browsing contexts may obtain a reference to it.

	==== Implementation ====		==== Implementation ====
Line 51:		Line 55:

	=== 2. "_unrelated" Target ===		=== 2. "_unrelated" Target ===
	This alternative solution uses a new <code>"_unrelated"</code> browsing context keyword for link targets instead of a new link type. The proposed behavior would still cause a link to open in a new, unnamed browsing context with a null <code>window.opener</code>, and with no reference to the new window ~~available~~ to the creator browsing context. Thus, the creator and new windows would be in different "units of related browsing contexts" (http://dev.w3.org/html5/spec/single-page.html#unit-of-related-browsing-contexts).		This alternative solution uses a new <code>"_unrelated"</code> browsing context keyword for link targets instead of a new link type. The proposed behavior would still cause a link to open in a new, unnamed browsing context with a null <code>window.opener</code>, and with no reference to the new window returned to the creator browsing context. Thus, the creator and new windows would be in different "units of related browsing contexts" (http://dev.w3.org/html5/spec/single-page.html#unit-of-related-browsing-contexts).

	==== Processing Model ====		==== Processing Model ====
Line 70:		Line 74:

	==== Limitations ====		==== Limitations ====
	As before, this proposal still requires the link to open in a new browsing context. This avoids any concerns with existing window references becoming inaccessible after a navigation to an unrelated browsing context.		As before, this proposal still requires the link to open in a new browsing context. This avoids any concerns with existing window references becoming inaccessible after a navigation to an unrelated browsing context. Again, if either window is named, it may still be discovered by other windows.

	==== Implementation ====		==== Implementation ====
Line 76:		Line 80:

	==== Adoption ====		==== Adoption ====
	Web app developers would use this feature to protect their app from user-contributed links, both in terms of script connections and resource contention in multi-process browsers.		Web app developers would use this feature to help protect their app from user-contributed links, both in terms of script connections and resource contention in multi-process browsers.

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

Creis at 22:57, 13 June 2012

2012-06-13T22:57:52Z

@@ Line 22: / Line 22: @@
 == Proposed Solutions ==
-=== "Unrelated" Link Type ===
+=== 1. "Unrelated" Link Type ===
 The proposed behavior would cause a link to open in a new, unnamed browsing context with a null <code>window.opener</code>, and with no reference to the new window available to the creator browsing context.  Thus, the creator and new windows would be in different "units of related browsing contexts" (http://dev.w3.org/html5/spec/single-page.html#unit-of-related-browsing-contexts).  There are two changes needed to support this: adding a link type for <code>"unrelated"</code> and providing a way to request this behavior with <code>window.open</code>.
@@ Line 48: / Line 48: @@
 ==== Adoption ====
 Web app developers would use this feature to protect their app from user-contributed links, both in terms of script connections and resource contention in multi-process browsers.
 [[Category:Proposals]]

Creis: Created page with 'Many sites link to untrusted pages that open in a new window. This proposal adds a way to open those links in an unrelated browsing context, to prevent unwanted interactions wit...'

2012-06-06T23:19:41Z

Created page with 'Many sites link to untrusted pages that open in a new window. This proposal adds a way to open those links in an unrelated browsing context, to prevent unwanted interactions wit...'

New page

Many sites link to untrusted pages that open in a new window. This proposal adds a way to open those links in an unrelated browsing context, to prevent unwanted interactions with the original site.

== Use Case Description ==
Many web apps open untrusted links in new windows, such as mail clients that allow users to click on links in email messages. These apps often want to avoid any detrimental effects from opening the untrusted page, such as script calls that try to manipulate or infer things about their <code>window.opener</code>, or slowdowns from being rendered in the same process of a multi-process browser.

=== Current Limitations ===
There is currently no adequate way for such web apps to express that a link should be opened in an unrelated browsing context, with no <code>window.opener</code> or other script connections to the web app.

=== Current Usage and Workarounds ===
The closest mechanism for getting this behavior is to add the <code>rel=noreferrer</code> and <code>target=_blank</code> attributes to a link (http://blog.chromium.org/2009/12/links-that-open-in-new-processes.html). This suppresses <code>window.opener</code>, and in Google Chrome it allows the link to be opened in a separate renderer process. However, it also requires web developers to block the Referer header. Some web apps have use cases for opening a link in an unrelated context while still desiring to pass the Referer (e.g., Google Reader).

Google Chrome also has a non-standard trick for opening links in a new process by using <code>window.open()</code>, setting the resulting window's <code>opener</code> to null, and then navigating the new window to a different site (http://www.google.com/chrome/intl/en/webmasters-faq.html#newtab). This trick is currently used by Gmail for links in messages. However, this is an awkward approach because it requires the creator page to have a reference to the new window, but then its access to the window is revoked. It also does not prevent script connections between the windows in other browsers, and it does not work for same origin links. If this proposal is adopted, Google Chrome could drop support for this trick.

Finally, WordPress uses the <code>"external"</code> link type for links that are "not part of the site that the current document forms a part of" (http://microformats.org/wiki/rel-external). This link type appears to have no impact on browser behavior, but WordPress has a plugin that uses JavaScript to open such links in a new window (http://wordpress.org/extend/plugins/rel-external/).

=== Benefits ===
Having explicit syntax for this use case would allow browsers to open links in an unrelated browsing context, while still passing the Referer header. This would mean that the original page would not receive a reference to the new window, and the new window would have a null <code>opener</code>. Multi-process browsers could also decide to use a separate renderer process for the new page, allowing it to render concurrently and fail independently.

=== Requests for this Feature ===
Requests are being tracked at http://crbug.com/69267, which has been starred 22 times. Many Google Apps developers have expressed interest in the feature, hoping to adopt it for use cases like links in Gmail messages.

== Proposed Solutions ==

=== "Unrelated" Link Type ===
The proposed behavior would cause a link to open in a new, unnamed browsing context with a null <code>window.opener</code>, and with no reference to the new window available to the creator browsing context. Thus, the creator and new windows would be in different "units of related browsing contexts" (http://dev.w3.org/html5/spec/single-page.html#unit-of-related-browsing-contexts). There are two changes needed to support this: adding a link type for <code>"unrelated"</code> and providing a way to request this behavior with <code>window.open</code>.

==== Processing Model ====
1) Add <code>"unrelated"</code> link type.
A <code>rel=unrelated</code> link would cause a link to open in an unrelated browsing context with no <code>window.opener</code> (similar to <code>rel=noreferrer target=_blank</code>). Setting this link type would imply <code>target=_blank</code>, even if a target is otherwise set in the link. For example:

<pre>
<a href="foo.html" rel="unrelated">Foo</a>
</pre>

2) Use <code>"unrelated"</code> with <code>window.open</code>.
JavaScript code should also be able to initiate a navigation in an unrelated browsing context. It would be easiest to use the "features" argument of <code>window.open</code> to specify this. As above, any window name would be ignored if <code>"unrelated"</code> was present in the features list. For example:

<pre>
var w = window.open("foo.html", "", "unrelated");
// Now w is null, and the new window has a null opener.
</pre>

==== Limitations ====
One issue with this approach is that http://dev.w3.org/html5/spec/single-page.html#dom-open says that the "features" argument of <code>window.open</code> should be ignored. However, supporting this type of additional behavior on <code>window.open</code> could be worth pursuing, since it could be useful for other link types (e.g., <code>"noreferrer"</code>) as well.

==== Implementation ====
Browser vendors could implement this new behavior by treating the navigation as if it loaded in a window created by the user. This is primarily a policy change, and it would help to better support use cases in many web apps.

==== Adoption ====
Web app developers would use this feature to protect their app from user-contributed links, both in terms of script connections and resource contention in multi-process browsers.

[[Category:Proposals]]