- From: Charlie Reis <creis@chromium.org>
- Date: Mon, 27 Aug 2012 17:29:37 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@lists.whatwg.org
On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson <ian@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
Received on Tuesday, 28 August 2012 00:30:06 UTC