[whatwg] Proposal for Links to Unrelated Browsing Contexts

[Charlie Reis]

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