- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 27 Aug 2012 23:28:45 -0700
- To: Charlie Reis <creis@chromium.org>
- Cc: whatwg@lists.whatwg.org, Ian Hickson <ian@hixie.ch>
I overlooked that it's also in the spec itself, not just the registry: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer Regards, 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:29:56 UTC