Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, 1 Oct 2012, Glenn Maynard wrote: 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 new browsing context It doesn't seem like you need a new browsing context to achieve both of the above. (Maybe it's easier to implement in today's multi-process browsers, if you happen to be opening a new tab at the same time you start a new process, but that seems like an implementation detail.) You need a new WindowProxy object, otherwise anything that had access to it before still has access, and thus can't be in a new event loop. Saying you need a new WindowProxy object is basically equivalent to saying you need a new browsing context. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 10/02/2012 02:34 AM, Boris Zbarsky wrote: On 10/1/12 6:10 PM, Ian Hickson wrote: On Tue, 19 Jun 2012, Boris Zbarsky wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. I'm happy to make the spec not match implementations, if the implementations are going to change to match the spec. :-) I certainly plan to change Gecko to make this stuff less lose there. I have no idea why this part of the spec is special enough to get undefined behaviour when we have tried to avoid it on general principle everywhere else.
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, 2 Oct 2012, James Graham wrote: On 10/02/2012 02:34 AM, Boris Zbarsky wrote: On 10/1/12 6:10 PM, Ian Hickson wrote: On Tue, 19 Jun 2012, Boris Zbarsky wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. I'm happy to make the spec not match implementations, if the implementations are going to change to match the spec. :-) I certainly plan to change Gecko to make this stuff less lose there. I have no idea why this part of the spec is special enough to get undefined behaviour when we have tried to avoid it on general principle everywhere else. Can you figure out how to describe what browsers do in more detail than the spec currently gives, and in a way where it makes sense to allow what that description covers but not subtly different things? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Summary: I've changed rel=noreferrer so that when it creates a new top-level browsing context, it doesn't clone sessionStorage. Turns out that as specced, it already did everything else that was needed. 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 The key part of this is: | Many web apps open untrusted links in new windows, such as mail clients | that allow users to click on links in email messages. These apps often | want to avoid any detrimental effects from opening the untrusted page, | such as script calls that try to manipulate or infer things about their | window.opener, or slowdowns from being rendered in the same process of a | multi-process browser. This is already possible with rel=noreferrer. On Mon, 27 Aug 2012, Charlie Reis wrote: 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= This is already possible using rel=noreferrer to create a new browsing context without a name. As a result, I think these are also necessary features: + have the new page be in a different unit of related browsing contexts This is already the case for rel=noreferrer, as far as I can tell, assuming that... + have the new page be in a new browsing context ...it's a new browsing context (e.g. target=_blank). + have window.opener not be set This is already the case for rel=noreferrer. + have the window.name of the new page be set to This is already the case unless you explicitly set one. But actually, even if you do, nothing forces the user agent to make it accessible, since the spec says that they're only accessible if the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, and the UA can easily decide not to allow it if the tabs aren't directly reachable browsing contexts in the spec's terms. Secondary goals: + have the sessionStorage not be cloned for the new page's browsing context Interesting. Done. Anti-goals: + have the referer header be cleared on the load of the new page (Discussed below.) 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. (Discussed below.) 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). rel=noreferrer supports this. From form action? I don't know of any immediate use cases for this, but it might be nice for consistency. I haven't supported this. In general, form doesn't support rel= features. 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. I meant is access blocked in both directions, as in, the new page can't see the original page and vice versa. The answer seems to be yes. 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.) For these use cases, blocking referrers seems like a good thing, or at least not a problem. On Wed, 6 Jun 2012, Michal Zalewski wrote: 1) How would this mechanism work with named windows (which may be targeted by means other than accessing opener.*)? In certain implementations (e.g., Chrome), the separation in this namespace comes free, but that's not given for other browsers. There are ways in which the attacker could, for example, load GMail in a window that already has window.name set. Yeah, if you set the name you're not going to necessarily have as good a separation. If you want this to work well, use target=_blank. 2) What would be the behavior of a rel=unrelated link with target= pointing to an existing iframe on the page? Could it work in any useful way? 3) What about the same with target= pointing to
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Oct 1, 2012 at 5:10 PM, Ian Hickson i...@hixie.ch wrote: + have the new page be in a new browsing context ...it's a new browsing context (e.g. target=_blank). I'm not very familiar with the browsing context concept: what's the practical security issue here? It should never be necessary to open a new window to invoke security features, since in general opening new windows without a good UI reason is extremely rude. (A good UI reason is this is an expensive-to-load web app that's typically used over a long term, so you rarely want to replace the tab with links, eg. Gmail. The all-too-common bad reason is we want people to keep pages open in the user's browser for long as possible in the hopes that it'll make them come back by accident, so we'll sprinkle target=_blank everywhere, eg. amazon.co.jp makes *every search result* target=_blank.) This is abused so constantly that I disable it with browser.link.open_newwindow in FF. If there are security features that are only accessible with target=_blank, they should be accessible without the antisocial behavior of opening new windows/tabs that the user didn't ask for. (If there are security issues with opening links in the same tab in the first place, I'm interested in knowing what they are.) -- Glenn Maynard
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 10/1/12 6:10 PM, Ian Hickson wrote: On Tue, 19 Jun 2012, Boris Zbarsky wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. I'm happy to make the spec not match implementations, if the implementations are going to change to match the spec. :-) I certainly plan to change Gecko to make this stuff less lose there. But full disclosure: I have been thus planning for at least 3 years. I don't know when I'll get to it. It's not a small change. :( -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, 1 Oct 2012, Glenn Maynard wrote: On Mon, Oct 1, 2012 at 5:10 PM, Ian Hickson i...@hixie.ch wrote: + have the new page be in a new browsing context ...it's a new browsing context (e.g. target=_blank). I'm not very familiar with the browsing context concept: what's the practical security issue here? I'm not aware of any particular security issues involved here. (A good UI reason is this is an expensive-to-load web app that's typically used over a long term, so you rarely want to replace the tab with links, eg. Gmail. Right, that's bascally the use case. See the top of my recent long e-mail on this thread. The all-too-common bad reason is we want people to keep pages open in the user's browser for long as possible in the hopes that it'll make them come back by accident, so we'll sprinkle target=_blank everywhere, eg. amazon.co.jp makes *every search result* target=_blank.) This is abused so constantly that I disable it with browser.link.open_newwindow in FF. Presumably authors in such cases would not use rel=noreferrer; I don't see why they would want to. On Mon, 1 Oct 2012, Boris Zbarsky wrote: I'm happy to make the spec not match implementations, if the implementations are going to change to match the spec. :-) I certainly plan to change Gecko to make this stuff less lose there. But full disclosure: I have been thus planning for at least 3 years. I don't know when I'll get to it. It's not a small change. :( Let me know when you've changed it, and I'll look into changing the spec again. Right now, I don't think it makes sense to go against the tide. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Oct 1, 2012 at 8:37 PM, Ian Hickson i...@hixie.ch wrote: The all-too-common bad reason is we want people to keep pages open in the user's browser for long as possible in the hopes that it'll make them come back by accident, so we'll sprinkle target=_blank everywhere, eg. amazon.co.jp makes *every search result* target=_blank.) This is abused so constantly that I disable it with browser.link.open_newwindow in FF. Presumably authors in such cases would not use rel=noreferrer; I don't see why they would want to. The only issue I'm concerned with is encouraging yet more target=_blank misuse by encouraging people to use it where opening a new window isn't genuinely appropriate to the UI. As long as there aren't security reasons to want a new browsing context, that's fine. It does seem orthogonal: 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 new browsing context It doesn't seem like you need a new browsing context to achieve both of the above. (Maybe it's easier to implement in today's multi-process browsers, if you happen to be opening a new tab at the same time you start a new process, but that seems like an implementation detail.) -- Glenn Maynard
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, 27 Aug 2012, Charlie Reis wrote: 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. Why does GMail need to use window.open()? Surely the right way to expose a link is to use a href=. What is forcing them to use window.open()? (Using window.open() has a number of negative side-effects, so if we could move them off that that would be a win. Furthermore, not having to support window.open() here would in general make this far easier. So if there really is a need to support window.open(), I would like to understand it.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Sep 24, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: Why does GMail need to use window.open()? Surely the right way to expose a link is to use a href=. What is forcing them to use window.open()? I can't speak for Gmail, but Google Reader uses window.open since it allows unrelated links to be opened in response to a key event (the v keyboard shortcut). It would also benefit from severing all ties to the opened window. Mihai
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 9/24/12 8:42 PM, Mihai Parparita wrote: On Mon, Sep 24, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: Why does GMail need to use window.open()? Surely the right way to expose a link is to use a href=. What is forcing them to use window.open()? I can't speak for Gmail, but Google Reader uses window.open since it allows unrelated links to be opened in response to a key event (the v keyboard shortcut). In most UAs this is also possible to do with a click() on the HTML a, no? In the ones in which it's _not_ possible that way, they should add it, perhaps? -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Aug 29, 2012 at 3:01 PM, Charlie Reis cr...@chromium.org wrote: On Tue, Aug 28, 2012 at 9:39 AM, Glenn Maynard gl...@zewt.org wrote: I had to do this recently (a script-initiated rel=noreferrer navigation). FYI, I worked around it by creating a temporary HTMLAnchorElement, setting its href and rel properties and calling click(). A way to do this directly with window.open would be nice, but it's orthogonal to noreferrer vs. unrelated. That's a fair point, actually. It would be possible to use noreferrer from script code (if somewhat inelegant). Do you mean the create an HTMLAnchorElement hack is inelegant? No argument there (which is why a way to do this with window.open would be nice). I don't know if it's inelegant enough to justify doing that, though (not something I'd bother to push for, myself), and it does seem to satisfy the use case of using noreferrer and unrelated from scripts. It's also worth noting that this proposal's cleaner syntax for window.open has no way to block the referrer if that's what the developers wanted. That means they'd have to choose between cleaner window.open syntax that passes the referrer or the workaround approach that blocks it. This proposal seemed to be effectively passing a rel value into window.open, which means you could say window.open(url, target, unrelated noreferrer). To be honest, I haven't heard strong enough support for the allow-referrer case to justify this proposal on the basis of cleaner syntax alone. Maybe we should table the discussion unless a stronger use case arises? (I don't have a personal need for rel=external, or even a complete understanding of the use cases, but it does seem orthogonal to noreferrer.) -- Glenn Maynard
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Aug 28, 2012 at 9:39 AM, Glenn Maynard gl...@zewt.org wrote: On Tue, Aug 28, 2012 at 11:18 AM, Charlie Reis cr...@chromium.org wrote: 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. That's not a difference between unrelated and noreferrer, though. It applies to noreferrer, too. I had to do this recently (a script-initiated rel=noreferrer navigation). FYI, I worked around it by creating a temporary HTMLAnchorElement, setting its href and rel properties and calling click(). A way to do this directly with window.open would be nice, but it's orthogonal to noreferrer vs. unrelated. -- Glenn Maynard That's a fair point, actually. It would be possible to use noreferrer from script code (if somewhat inelegant). It's also worth noting that this proposal's cleaner syntax for window.open has no way to block the referrer if that's what the developers wanted. That means they'd have to choose between cleaner window.open syntax that passes the referrer or the workaround approach that blocks it. To be honest, I haven't heard strong enough support for the allow-referrer case to justify this proposal on the basis of cleaner syntax alone. Maybe we should table the discussion unless a stronger use case arises? (I'm aware that this doesn't resolve the question of whether named windows should be discoverable outside their unit of related browsing contexts. Perhaps that can be discussed further separately.) Sound reasonable? Charlie ps-- I'll be away from email from tomorrow until September 12, but can follow up with any further discussion after that.
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
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 cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@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
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
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 m...@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 cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@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
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
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 m...@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 cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@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
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Aug 27, 2012 at 11:43 PM, Maciej Stachowiak m...@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 m...@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 cr...@chromium.org wrote: On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@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
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Aug 28, 2012 at 11:18 AM, Charlie Reis cr...@chromium.org wrote: 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. That's not a difference between unrelated and noreferrer, though. It applies to noreferrer, too. I had to do this recently (a script-initiated rel=noreferrer navigation). FYI, I worked around it by creating a temporary HTMLAnchorElement, setting its href and rel properties and calling click(). A way to do this directly with window.open would be nice, but it's orthogonal to noreferrer vs. unrelated. -- Glenn Maynard
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
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? + have window.opener not be set + have the window.name of the new page be set to + have the window of the new page not be able to reach the opener via a named window.open() or target= + have the referer header be cleared on the load of the new page + have the sessionStorage not be cloned for the new page's browsing context + have the new page use a different event loop if possible (new process) + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have the new page be in the same browsing context Does this need to be done from window.open()? From a href? From form action? Is this a symmetric feature? At a more fundamental level: what are the use cases here? Is it just e-mail clients that want to open links? What are the attack scenarios? Is it just links in e-mails getting at the e-mail app somehow? 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson i...@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
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, Jun 28, 2012 at 9:00 PM, Charlie Reis cr...@chromium.org wrote: What's the next step for this proposal? Hixie, does the _unrelated target approach sound good to you at this point? http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts FWIW, all emails to the list will be read by the editor of the relevant specification and replied to in due course. If there's some kind of hurry, you can ask to prioritize (usually done over IRC/IM). -- http://annevankesteren.nl/
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 19, 2012 at 2:52 PM, Charlie Reis cr...@chromium.org wrote: On Tue, Jun 19, 2012 at 2:16 PM, James Graham jgra...@opera.com wrote: The way the process here works is that Hixie reads these emails agrees that the change is a good idea (hopefully; in this case it seems likely since we seem to have three implementors in agreement) and it happens. There isn't any need for seperate proposals. Sounds good. This is my first proposal to the group, so I wasn't familiar. Just didn't want to get too sidetracked from the main feature, since I imagine there could be other opinions about narrowing the scope of window names. What's the next step for this proposal? Hixie, does the _unrelated target approach sound good to you at this point? http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts Thanks, Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. Firefox appears to allow cross-origin windows find each other by name. This is actually necessary for web compat, last I checked, if the cross-origin window is one that you opened or one that you are framing. Do other UAs not allow navigating the cross-origin window in those situations? There are lots of cases in which cross-origin windows in fact cannot find each other by name in Firefox. Perhaps that's the bug you're referring to? No, I'm talking about the fact that Firefox just has no concept of related browsing context and treats them all as related. -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. Then the wording should be changed. However, that belongs in a different proposal than this one. Firefox appears to allow cross-origin windows find each other by name. This is actually necessary for web compat, last I checked, if the cross-origin window is one that you opened or one that you are framing. Do other UAs not allow navigating the cross-origin window in those situations? Those cases are explicitly allowed in http://dev.w3.org/html5/spec/single-page.html#allowed-to-navigate, and other user agents also support that case. (I tested by navigating a named window I had opened and navigated cross-origin. I confirmed that Chrome, Safari, Firefox, and Opera all let the opener window find the named cross-origin window. IE doesn't work in that case, though.) There are lots of cases in which cross-origin windows in fact cannot find each other by name in Firefox. In my earlier email, I was testing a case where window A opens a named window B. I then navigate B to a different origin and create window C from scratch. C is able to find B by name in Firefox, but not in other user agents. (That's consistent with your description that Firefox considers all windows related.) Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, 19 Jun 2012, Charlie Reis wrote: On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. Then the wording should be changed. However, that belongs in a different proposal than this one. The way the process here works is that Hixie reads these emails agrees that the change is a good idea (hopefully; in this case it seems likely since we seem to have three implementors in agreement) and it happens. There isn't any need for seperate proposals. Of course it is also possible to file a bug if you want to track this specific point. (I sort of thought I had already filed a bug here but I can't find it now so maybe I imagined it). (aside: your mail client seems to be mangling quotes in plaintext mail. This makes your replies very hard to follow).
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 19, 2012 at 2:16 PM, James Graham jgra...@opera.com wrote: The way the process here works is that Hixie reads these emails agrees that the change is a good idea (hopefully; in this case it seems likely since we seem to have three implementors in agreement) and it happens. There isn't any need for seperate proposals. Sounds good. This is my first proposal to the group, so I wasn't familiar. Just didn't want to get too sidetracked from the main feature, since I imagine there could be other opinions about narrowing the scope of window names. Of course it is also possible to file a bug if you want to track this specific point. (I sort of thought I had already filed a bug here but I can't find it now so maybe I imagined it). (aside: your mail client seems to be mangling quotes in plaintext mail. This makes your replies very hard to follow). Sorry about that. It seems to have come out ok in the web archive (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-June/036442.html), but I'm trying Gmail's Plain Text mode here to see if that helps. Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, Jun 14, 2012 at 10:45 AM, Charlie Reis cr...@chromium.org wrote: I do observe that Safari, IE, and even Opera currently allow windows in unrelated contexts to discover named windows, though. Just do a window.open(foo.html, foo) from two independently opened windows and they'll both target the same foo window. As a result, making unrelated browsing contexts inaccessible to each other would probably require changes to most user agents. I'm ok either way: allowing named but unrelated windows to be discovered or not. I'm going to go out on a limb and say that it's ok if named but unrelated windows are able to discover each other. This is already the case for windows in unrelated browsing contexts in most single-process browsers, and (as Boris points out) it already happens in Chrome when renderer processes are shared. That means developers need to handle it anyway. Thus, this proposal is mainly about preventing window.opener from being set and causing window.open to return null. I've updated the wiki to reflect this (in Benefits and Limitations): http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts If we want to change that behavior and make all window names be specific to their unit of related browsing contexts (for all user agents), that should probably be proposed separately. Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 6/18/12 6:10 PM, Charlie Reis wrote: I'm going to go out on a limb and say that it's ok if named but unrelated windows are able to discover each other. I actually don't; I think the fact that it happens in Firefox is a (longstanding) bug that needs to get fixed. If we want to change that behavior and make all window names be specific to their unit of related browsing contexts I believe the spec already does that, actually. -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, 14 Jun 2012 01:44:12 +0200, Michal Zalewski lcam...@coredump.cx
wrote:
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly?
rel=noreferrer already has this feature, FWIW.
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer
This keyword also causes the opener attribute to remain null if the
hyperlink creates a new browsing context.
The
degree of separation between browsing contexts is intuitive in the
case of Chrome, given the underlying implementations, but will it be
the same for Internet Explorer or Firefox or Safari?
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right? That may be unexpected.
The same goes the other way - the spec subtly implies that because
window.open('foo', '_unrelated') returns null, the opener will not be
able to mess with the opened window, but that's not guaranteed given
that the reference may be leaked by other means, right?
/mz
--
Simon Pieters
Opera Software
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 06/14/2012 04:06 AM, Boris Zbarsky wrote:
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different ones, based on whatever
heuristics it uses for deciding whether it's spawned enough processes.
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right?
The spec needs to require that this be prevented
So AFAICT the spec does require that this is prevented for unrelated
browsing contexts, except in the case where the two are same-origin
which is allowed but with some fuzzy condition about [if] the user
agent determines that the two browsing contexts are related enough that
it is ok if they reach each other. As far as I can tell only Gecko
implements that and it seems reasonable that others wouldn't want to
have behaviour that requires multiple event loops to interact (assuming
one event loop per unit of related browsing context).
Therefore I think that part of the spec should be changed to only reuse
the same named window within a single unit of related browsing context.
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, Jun 14, 2012 at 4:04 AM, James Graham jgra...@opera.com wrote:
On 06/14/2012 04:06 AM, Boris Zbarsky wrote:
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different ones, based on whatever
heuristics it uses for deciding whether it's spawned enough processes.
True, though that doesn't mean they need to share the same name scope.
Right now, you're correct: Chrome does allow this named window discovery
when renderer processes are re-used. However, we could probably look into
using a separate WebKit PageGroup when re-using a process so that names
stay local to their unit of related browsing contexts.
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right?
The spec needs to require that this be prevented
So AFAICT the spec does require that this is prevented for unrelated
browsing contexts, except in the case where the two are same-origin which
is allowed but with some fuzzy condition about [if] the user agent
determines that the two browsing contexts are related enough that it is ok
if they reach each other. As far as I can tell only Gecko implements that
and it seems reasonable that others wouldn't want to have behaviour that
requires multiple event loops to interact (assuming one event loop per unit
of related browsing context).
Therefore I think that part of the spec should be changed to only reuse
the same named window within a single unit of related browsing context.
I would be happy to see that happen, for the same reason as you (allowing
user agents to have one event loop or process per unit of related browsing
contexts). I'm not sure how to interpret the current wording of the spec
in this case.
I do observe that Safari, IE, and even Opera currently allow windows in
unrelated contexts to discover named windows, though. Just do a
window.open(foo.html, foo) from two independently opened windows and
they'll both target the same foo window. As a result, making unrelated
browsing contexts inaccessible to each other would probably require changes
to most user agents.
I'm ok either way: allowing named but unrelated windows to be discovered or
not.
Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 12, 2012 at 7:39 AM, Charlie Reis cr...@chromium.org wrote: On Mon, Jun 11, 2012 at 11:24 PM, Anne van Kesteren ann...@annevk.nlwrote: Having a rel attribute imply a target attribute value seems bad. Thus far they have been orthogonal. Maybe it should be a new target attribute value instead? I'm not opposed to that, and it does seem simpler. Something like target=_unrelated? Thanks for the suggestion. I've updated http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts with a second proposed solution for target=_unrelated (similar to target=_blank, but in an unrelated context). It works better for the window.open case as well. Any feedback on this revised approach? Thanks, Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly? The
degree of separation between browsing contexts is intuitive in the
case of Chrome, given the underlying implementations, but will it be
the same for Internet Explorer or Firefox or Safari?
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right? That may be unexpected.
The same goes the other way - the spec subtly implies that because
window.open('foo', '_unrelated') returns null, the opener will not be
able to mess with the opened window, but that's not guaranteed given
that the reference may be leaked by other means, right?
/mz
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 13, 2012 at 4:44 PM, Michal Zalewski lcam...@coredump.cxwrote:
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly? The
degree of separation between browsing contexts is intuitive in the
case of Chrome, given the underlying implementations, but will it be
the same for Internet Explorer or Firefox or Safari?
That's a fair point, since those browsers have a global namespace for
windows. You're right that the main change would be not setting
window.opener or returning a value from window.open, even though the
windows might find each other through other means in those browsers.
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right? That may be unexpected.
The same goes the other way - the spec subtly implies that because
window.open('foo', '_unrelated') returns null, the opener will not be
able to mess with the opened window, but that's not guaranteed given
that the reference may be leaked by other means, right?
/mz
Correct. In that example, the new window could give itself a name, and the
opener would then be able to find it (in browsers with a global namespace
for windows).
I'm not sure how easy it would be to create a different namespace for the
unrelated window in other browsers, and I don't expect that to change. I
still think this proposal can be useful, though, especially for an unnamed
window trying to open an untrusted link.
It's worth noting that pages that don't want to be found already either
have to clear their name or use an unpredictable one, and that wouldn't
change here.
I can call this issue out more explicitly in the proposal if you'd prefer.
Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different ones, based on whatever
heuristics it uses for deciding whether it's spawned enough processes.
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right?
The spec needs to require that this be prevented
-Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Jun 11, 2012 at 11:32 PM, Charlie Reis cr...@chromium.org wrote: Any other feedback on this proposal? http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts Having a rel attribute imply a target attribute value seems bad. Thus far they have been orthogonal. Maybe it should be a new target attribute value instead? -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, Jun 11, 2012 at 11:24 PM, Anne van Kesteren ann...@annevk.nlwrote: On Mon, Jun 11, 2012 at 11:32 PM, Charlie Reis cr...@chromium.org wrote: Any other feedback on this proposal? http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts Having a rel attribute imply a target attribute value seems bad. Thus far they have been orthogonal. Maybe it should be a new target attribute value instead? I'm not opposed to that, and it does seem simpler. Something like target=_unrelated? Charlie -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, Jun 7, 2012 at 9:21 AM, Charlie Reis cr...@chromium.org wrote: On Wed, Jun 6, 2012 at 11:47 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. I don't see this as any different from using target=_blank or window.open. The same popup restrictions would apply. This link type wouldn't make much sense on a same-window navigation, in my opinion. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons. He's saying he wants it to force target=_blank, though. That doesn't seem necessary. Why not navigate the current window to a new document in an unrelated browsing context? Adam That would hit all the problems Michal brought up, where you might target an existing window or iframe, causing existing references to the window to no longer be valid. That could be harder for browser vendors to implement. I do think it would be cleanest to have it open in a new window, using target=_blank. Charlie Any other feedback on this proposal? http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts Thanks, Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons. He's saying he wants it to force target=_blank, though. That doesn't seem necessary. Why not navigate the current window to a new document in an unrelated browsing context? Adam
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 6, 2012 at 11:47 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius svartma...@gmail.com wrote: On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. I don't see this as any different from using target=_blank or window.open. The same popup restrictions would apply. This link type wouldn't make much sense on a same-window navigation, in my opinion. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons. He's saying he wants it to force target=_blank, though. That doesn't seem necessary. Why not navigate the current window to a new document in an unrelated browsing context? Adam That would hit all the problems Michal brought up, where you might target an existing window or iframe, causing existing references to the window to no longer be valid. That could be harder for browser vendors to implement. I do think it would be cleanest to have it open in a new window, using target=_blank. Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Several questions: 1) How would this mechanism work with named windows (which may be targeted by means other than accessing opener.*)? In certain implementations (e.g., Chrome), the separation in this namespace comes free, but that's not given for other browsers. There are ways in which the attacker could, for example, load GMail in a window that already has window.name set. 2) What would be the behavior of a rel=unrelated link with target= pointing to an existing iframe on the page? Could it work in any useful way? 3) What about the same with target= pointing to an existing window? Would that window become isolated? What would happen to the 'back' button / history.back()?
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
I'm hoping to bypass all of those by overriding any specification of target in the link. That is, if rel=unrelated is specified, that forces target to be _blank. Charlie On Wed, Jun 6, 2012 at 4:53 PM, Michal Zalewski lcam...@coredump.cx wrote: Several questions: 1) How would this mechanism work with named windows (which may be targeted by means other than accessing opener.*)? In certain implementations (e.g., Chrome), the separation in this namespace comes free, but that's not given for other browsers. There are ways in which the attacker could, for example, load GMail in a window that already has window.name set. 2) What would be the behavior of a rel=unrelated link with target= pointing to an existing iframe on the page? Could it work in any useful way? 3) What about the same with target= pointing to an existing window? Would that window become isolated? What would happen to the 'back' button / history.back()?
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 6, 2012 at 6:56 PM, Charlie Reis cr...@chromium.org wrote: I'm hoping to bypass all of those by overriding any specification of target in the link. That is, if rel=unrelated is specified, that forces target to be _blank. Please don't encourage yet more sites to open new tabs when I didn't ask for it. -- Glenn Maynard
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons.
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons. He's saying he wants it to force target=_blank, though. -- Glenn Maynard
