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

On Mon, Aug 27, 2012 at 11:43 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>
> 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

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.

The other difference is that this proposal supports script-initiated
navigations, such as window.open(url, "_unrelated").  Gmail is one case
that depends on using JavaScript to open links from email messages, and so
it cannot use the rel=noreferrer syntax.

If I had to rank those two differences in order of importance, I'd say it's
more important to support window.open than allowing the referrer, but it
would be nice to have both.

Hope that helps,
Charlie

>
>
> 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 16:18:41 UTC