[whatwg] Proposal for Links to Unrelated Browsing Contexts

[Maciej Stachowiak]

I overlooked that it's also in the spec itself, not just the registry:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer

Regards,
Maciej

On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 
> Someone earlier in the thread mentioned that this feature sounds an awful lot like rel=noreferrer, which has been in WebKit for several years:
> http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/
> 
> It is also mentioned in the official link relation registry:
> http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
> 
> Do you have a use case for your new proposal that is not handled by <a href="..." rel=noreferrer target=_blank>? Does it have a materially different effect? (I can't tell.)
> 
> Regards,
> Maciej
> 
> 
> On Aug 27, 2012, at 5:29 PM, Charlie Reis <creis at chromium.org> wrote:
> 
>> On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> 
>>> On Wed, 6 Jun 2012, Charlie Reis wrote:
>>>> 
>>>> I've posted a new proposal to the WhatWG wiki to give web sites a way
>>>> to open a link in an unrelated browsing context.  These links would open
>>>> in a new window with no script connections back to the original site,
>>>> which is useful for web apps like Gmail that open user-contributed
>>>> links.  Also, this could allow multi-process browsers like Google Chrome
>>>> to open the new page in a separate process.
>>>> 
>>>> Any feedback on the proposal is appreciated!
>>>> http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts
>>> 
>>> It's not entirely clear to me what the desired behaviour is here. Which of
>>> the following are considered features that we need to provide? Which are
>>> secondary goals, which are non-goals, which are anti-goals?
>> 
>> 
>> I think our discussion found this feature would be most useful if the new
>> page was unable to find its opener, so I'd group things as follows.
>> 
>> Primary goals:
>> + have the new page use a different event loop if possible (new process)
>> + have the window of the new page not be able to reach the opener via
>>  a named window.open() or target=""
>> 
>> As a result, I think these are also necessary features:
>> + have the new page be in a different unit of related browsing contexts
>> + have the new page be in a new browsing context
>> + have "window.opener" not be set
>> + have the window.name of the new page be set to ""
>> 
>> Secondary goals:
>> + have the sessionStorage not be cloned for the new page's browsing
>>  context
>> 
>> Non-goals:
>> + have the new page be in the same browsing context
>> 
>> Anti-goals:
>> + have the referer header be cleared on the load of the new page
>> 
>> 
>>> Does this need to be done from window.open()?
>> 
>> Yes.  For example, Gmail uses window.open() for the links in emails, but
>> would like the links to open in an unrelated context.
>> 
>>> From <a href>?
>> 
>> Yes.  For example, links to switch between apps within a domain would be
>> useful to have open in an unrelated context (e.g., the black bar at the top
>> of Google pages).
>> 
>>> From <form action>?
>> 
>> I don't know of any immediate use cases for this, but it might be nice for
>> consistency.
>> 
>>> Is this a symmetric feature?
>> 
>> Sorry, I'm not sure what you mean by symmetric here.  The page opened in
>> the unrelated context may also be able to open pages in another unrelated
>> context.
>> 
>>> At a more fundamental level: what are the use cases here? Is it just
>>> e-mail clients that want to open links?
>> 
>> Links in email clients is one use case.  For user agents that can open such
>> links in a different event loop, another use case is to allow multiple
>> independent apps under the same domain to run in parallel, even when
>> opening one app from another.  (For example, Chrome could open links to
>> different Google apps like Search, Maps, Mail, etc, in different processes.)
>> 
>> Even in user agents where all pages share the same event loop, this can be
>> useful to help enforce modularity in large applications (e.g., stopping a
>> developer in one part of a large site from introducing a scripting
>> dependency on another part of the site).  That's admittedly a secondary
>> benefit, and not the primary goal.
>> 
>>> What are the attack scenarios? Is
>>> it just links in e-mails getting at the e-mail app somehow?
>> 
>> The attack scenarios are about protecting any web app from unwanted script
>> calls or navigation attempts from untrusted pages in windows that it opens.
>> You could imagine anything from a mail client to a news reader to a social
>> network using it for links to external content.
>> 
>> Beyond defending against those attacks, the feature is also about allowing
>> unrelated pages to run on parallel event loops, so they aren't blocked on
>> each other.
>> 
>> 
>>> Without more details like the above it's hard to evaluate the proposals.
>>> 
>>> --
>>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> 
>> I hope that clarifies things!  It wasn't initially clear whether preventing
>> any access from the new page to the opener window (e.g., by finding the
>> named window) was necessary, but it does seem like the feature would be
>> most useful if that were the case.
>> 
>> Charlie
>