A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on IRC (such as one of these permanent autoconfirmed members).

Difference between revisions of "Links to Unrelated Browsing Contexts"

From WHATWG Wiki
Jump to: navigation, search
(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...')
(No difference)

Revision as of 23:19, 6 June 2012

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 script connections 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/).


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.

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 window.opener, 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 "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.


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.


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.


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.