Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

Summary: I've changed rel=noreferrer so that when it creates a new 
top-level browsing context, it doesn't clone sessionStorage. Turns out 
that as specced, it already did everything else that was needed.

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

The key part of this is:

| 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.

This is already possible with rel=noreferrer.


On Mon, 27 Aug 2012, Charlie Reis wrote:
> 
> 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=""

This is already possible using rel=noreferrer to create a new browsing 
context without a name.


> As a result, I think these are also necessary features:
>  + have the new page be in a different unit of related browsing contexts

This is already the case for rel=noreferrer, as far as I can tell, 
assuming that...

>  + have the new page be in a new browsing context

...it's a new browsing context (e.g. target="_blank").


>  + have "window.opener" not be set

This is already the case for rel=noreferrer.


>  + have the window.name of the new page be set to ""

This is already the case unless you explicitly set one. But actually, even 
if you do, nothing forces the user agent to make it accessible, since the 
spec says that they're only accessible if "the user agent determines that 
the two browsing contexts are related enough that it is ok if they reach 
each other", and the UA can easily decide not to allow it if the tabs 
aren't "directly reachable browsing contexts" in the spec's terms.


> Secondary goals:
>  + have the sessionStorage not be cloned for the new page's browsing
>    context

Interesting. Done.


> Anti-goals:
>  + have the referer header be cleared on the load of the new page

(Discussed below.)


> > 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.

(Discussed below.)


> > 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).

rel=noreferrer supports this.


> > From <form action>?
> 
> I don't know of any immediate use cases for this, but it might be nice 
> for consistency.

I haven't supported this. In general, <form> doesn't support rel="" 
features.


> > 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.

I meant "is access blocked in both directions", as in, the new page can't 
see the original page and vice versa. The answer seems to be yes.


> > 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.)

For these use cases, blocking referrers seems like a good thing, or at 
least not a problem.


On Wed, 6 Jun 2012, Michal Zalewski wrote:
> 
> 1) How would this mechanism work with named windows (which may be 
> targeted by means other than accessing opener.*)? In certain 
> implementations (e.g., Chrome), the separation in this namespace comes 
> free, but that's not given for other browsers. There are ways in which 
> the attacker could, for example, load GMail in a window that already has 
> window.name set.

Yeah, if you set the name you're not going to necessarily have as good a 
separation. If you want this to work well, use target="_blank".


> 2) What would be the behavior of a rel=unrelated link with target= 
> pointing to an existing iframe on the page? Could it work in any useful 
> way?
> 3) What about the same with target= pointing to an existing window? 
> Would that window become isolated? What would happen to the 'back' 
> button / history.back()?

It drops the referrer, but that's all, basically.


On Wed, 6 Jun 2012, Adam Barth wrote:
> 
> That doesn't seem necessary.  Why not navigate the current window to a 
> new document in an unrelated browsing context?

Browsers can do that if they want, but a new browsing context implies a 
new session history and I think it'd be really confusing for a link to 
seem to work like any normal link except it neuters the back button, or 
otherwise makes the history act in a special way.


On Thu, 14 Jun 2012, James Graham wrote:
> 
> [...] except in the case where the two are same-origin which is allowed 
> but with some fuzzy condition about "[if] the user agent determines that 
> the two browsing contexts are related enough that it is ok if they reach 
> each other". As far as I can tell only Gecko implements that and it 
> seems reasonable that others wouldn't want to have behaviour that 
> requires multiple event loops to interact (assuming one event loop per 
> unit of related browsing context).
> 
> Therefore I think that part of the spec should be changed to only reuse 
> the same named window within a single unit of related browsing contexts.

I haven't changed this, but it doesn't seem that unreasonable. Does anyone 
have any tests of this? In particular, do browsers really guarantee that 
you can reach _any_ browsing context in a unit of related browsing 
contexts? Or is it sometimes more strict than this? Is Gecko going to 
change in the other direction, making things tighter? Is Chrome, in the 
case of reused processes? Charlie even suggests that Safari, IE, and Opera 
allow different unrelated windows to find each other; if that is the case, 
it's not clear that the spec should change since that puts all the 
browsers on the side of matching the spec. :-)

(If we change this (change "related enough" to "in the same unit of 
related browsing contexts"), then even a named browsing context, assuming 
the name is new and doesn't end up referring to an existing window, would 
be cut off in the way we're describing above regarding event loops.)


On Tue, 19 Jun 2012, Boris Zbarsky wrote:
> On 6/19/12 1:56 PM, Charlie Reis wrote:
> > That's from the "[if] the user agent determines that the two browsing 
> > contexts are related enough that it is ok if they reach each other" 
> > part, which is quite vague.
> 
> This is, imo, the part that says unrelated browsing contexts should not 
> be able to reach each other by name.
> 
> It's only vague because hixie wanted all current implementations to be 
> conforming, I think.  Which I believe is a mistake.

I'm happy to make the spec not match implementations, if the 
implementations are going to change to match the spec. :-)


> > Firefox appears to allow cross-origin windows find each other by name.
> 
> This is actually necessary for web compat, last I checked, if the 
> cross-origin window is one that you opened or one that you are framing.  

The spec enumerates a set of cases where it's ok.


On Mon, 27 Aug 2012, Maciej Stachowiak wrote:
> 
> I'm still not clear on the use case for nulling the opener but still 
> sending the Referer header. It seems like it is better for mail clients 
> to clear referrer. What kinds of web apps need to open new windows and 
> null window.opener, but still send Referer?
> 
> The reason I'm asking is that it seems regrettable to have two link 
> types with such similar but subtly different behavior.

Agreed.


On Tue, 28 Aug 2012, Charlie Reis wrote:
> 
> There are two main differences from the rel=noreferrer feature.  First 
> (as you note), this does still send the referrer.  That's useful for 
> sites that don't want to be affected by the newly opened page but that 
> still rely on referrers for analytics.  From my earlier examples, that 
> might include links in social networks (where the social network might 
> want to be seen as the source of the referral) or links between apps on 
> the same domain.  I suppose it could also be useful for ads.

These are different use cases than the GMail case.


On Tue, 28 Aug 2012, Glenn Maynard wrote:
> 
> I had to do this recently (a script-initiated rel=noreferrer 
> navigation). FYI, I worked around it by creating a temporary 
> HTMLAnchorElement, setting its href and rel properties and calling 
> click().  A way to do this directly with window.open would be nice, but 
> it's orthogonal to noreferrer vs. unrelated.

On Wed, 29 Aug 2012, Charlie Reis wrote:
> 
> That's a fair point, actually.  It would be possible to use noreferrer 
> from script code (if somewhat inelegant).

Even better is to just use a real link and have the user really click it. 
No need for script-initiated anything, then.


> To be honest, I haven't heard strong enough support for the 
> allow-referrer case to justify this proposal on the basis of "cleaner 
> syntax" alone. Maybe we should table the discussion unless a stronger 
> use case arises?

Ok.


On Mon, 24 Sep 2012, Mihai Parparita wrote:
> 
> I can't speak for Gmail, but Google Reader uses window.open since it 
> allows "unrelated" links to be opened in response to a key event (the 
> "v" keyboard shortcut). It would also benefit from severing all ties to 
> the opened window.

There's still a real link in this case, though, no? So you can call 
.click() on it. (Or use accesskey=""...)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 1 October 2012 22:11:12 UTC