Difference between revisions of "Links to Unrelated Browsing Contexts"
(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...')
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.
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
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
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.
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
"unrelated" link type.
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>
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.