[whatwg] Proposal for Links to Unrelated Browsing Contexts

[Maciej Stachowiak]

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