- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 27 Aug 2012 23:43:35 -0700
- To: Charlie Reis <creis@chromium.org>
- Cc: whatwg@lists.whatwg.org, Ian Hickson <ian@hixie.ch>
James pointed out to me that the proposal explains the difference to noreferrer, which is essential that it *does* send a referrer, but has the rel=noreferrer behavior of nulling out window.opener. 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. Cheers, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak <mjs@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@chromium.org> wrote: > >> 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 06:44:00 UTC