Links to Unrelated Browsing Contexts

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 window.opener, 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 window.opener or other immediate script references to the web app.

Current Usage and Workarounds

The closest mechanism for getting this behavior is to add the rel=noreferrer and target=_blank attributes to a link (http://blog.chromium.org/2009/12/links-that-open-in-new-processes.html). This suppresses window.opener, 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 window.open(), setting the resulting window's opener 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 "external" 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 opener. 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 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

1. "Unrelated" Link Type

The proposed behavior would cause a link to open in a new, unnamed browsing context with a null window.opener, 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 "unrelated" and providing a way to request this behavior with window.open.

Processing Model

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

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

2) Use "unrelated" with window.open. 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 window.open to specify this. As above, any window name would be ignored if "unrelated" was present in the features list. For example:

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

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 window.open should be ignored. However, supporting this type of additional behavior on window.open could be worth pursuing, since it could be useful for other link types (e.g., "noreferrer") 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

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.

2. "_unrelated" Target

This alternative solution uses a new "_unrelated" 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 window.opener, 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

Using target="_unrelated" would cause a link to open in an unrelated browsing context with no window.opener. This would require adding "_unrelated" to the list of browsing context keywords, alongside "_blank", "_self", "_parent", and "_top". For example:

<a href="foo.html" target="_unrelated">Foo</a>

JavaScript code should also be able to initiate a navigation in an unrelated browsing context. The same logic should take effect if "_unrelated" is used as the "target" argument to window.open. For example:

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

Compared to the rel=unrelated proposed solution, this approach has the advantage that it does not need to implicitly override a target that the page may have specified, and it requires no major changes to window.open.

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. Again, if either window is named, it may still be discovered by other windows.

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 help protect their app from user-contributed links, both in terms of script connections and resource contention in multi-process browsers.