Re: [whatwg] @sandbox and navigation top
On Fri, 12 Feb 2010, Adam Barth wrote: Can a frame in @sandbox ever navigation the top-level frame? Not without a user prompt, currently. If not, that would make it hard to use @sandbox to contain advertisements, which want to navigate |top| when the user clicks on the ad. On Fri, 12 Feb 2010, Michal Zalewski wrote: Ads would want to be able to do that, but user-controlled gadgets shouldn't. On Fri, 12 Feb 2010, Adam Barth wrote: Perhaps we want an allow-frame-busting directive? In the implementation we have an allow-navigation bit that covers navigation |top| as well as window.open, etc. Maybe we want a more general directive that twiddles this bit? On Sat, 13 Feb 2010, Michal Zalewski wrote: I'm wondering if sites want to have control over the type of navigation: navigating the top-level context versus opening a new window? In particular, I am thinking about ads in embeddable gadgets (on social sites, or in places such as Docs, Wave, etc): you do not want the gadget to interfere with the presentation of the page by triggering disruptive and unsolicited top frame transitions (as this could be used for a crude DoS - in fact, IIRC, there is some history along these lines), but you may be OK with a pop-up ad following a click. On Sat, 13 Feb 2010, Adam Barth wrote: Yeah, I think there are use cases for both top-level navigation and window.open from sandboxed context. I suspect there's some trade off between complexity and fine-grained control. On Sat, 13 Feb 2010, Maciej Stachowiak wrote: Some may want to have a directive that allows only opening new windows and not navigating the top level. This is the policy Caja tries to enforce by default for instance. For ads I could imagine wanting only top-level navigation and not window opening. So maybe this should be two flags. On Sat, 13 Feb 2010, Markus Ernst wrote: An allow-navigation directive should IMO be ok. Given that a navigation element is allowed in the context, the user experience should actually not differ whether it is clicked in a sandboxed context or not. Let's start with just frame busting, and then add the ability to open popups once we have more experience with frame busting. I've added the keyword allow-top-navigation that allows pages to navigate their top-level browsing context. Some off-topic thoughts about this: Most non-academic websites apply target=_blank on all external links. In order to allow a consistent user experience, it might be worth to encourage UAs to offer the following user settings: 1. Open new tabs rather than windows This should not only apply to windows opened with target=_blank (as it is already possible e.g. in Firefox), but also to the ones opened by window.open(). 2. Always open links to other domains in a new tab (resp. window, if the above option is not set) I would even encourage to set this as the default, as it is a de-facto standard at least in commercial and community websites. This seems like something that would belong in a UA UI guide, rather than the HTML5 spec. The spec doesn't even mention tabs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] @sandbox and navigation top
Perhaps we want an allow-frame-busting directive? In the implementation we have an allow-navigation bit that covers navigation |top| as well as window.open, etc. Maybe we want a more general directive that twiddles this bit? I'm wondering if sites want to have control over the type of navigation: navigating the top-level context versus opening a new window? In particular, I am thinking about ads in embeddable gadgets (on social sites, or in places such as Docs, Wave, etc): you do not want the gadget to interfere with the presentation of the page by triggering disruptive and unsolicited top frame transitions (as this could be used for a crude DoS - in fact, IIRC, there is some history along these lines), but you may bey OK with a pop-up ad following a click. /mz
Re: [whatwg] @sandbox and navigation top
On Sat, Feb 13, 2010 at 12:08 AM, Michal Zalewski lcam...@coredump.cx wrote: Perhaps we want an allow-frame-busting directive? In the implementation we have an allow-navigation bit that covers navigation |top| as well as window.open, etc. Maybe we want a more general directive that twiddles this bit? I'm wondering if sites want to have control over the type of navigation: navigating the top-level context versus opening a new window? In particular, I am thinking about ads in embeddable gadgets (on social sites, or in places such as Docs, Wave, etc): you do not want the gadget to interfere with the presentation of the page by triggering disruptive and unsolicited top frame transitions (as this could be used for a crude DoS - in fact, IIRC, there is some history along these lines), but you may bey OK with a pop-up ad following a click. Yeah, I think there are use cases for both top-level navigation and window.open from sandboxed context. I suspect there's some trade off between complexity and fine-grained control. Adam
Re: [whatwg] @sandbox and navigation top
On Feb 12, 2010, at 11:54 PM, Adam Barth wrote: On Fri, Feb 12, 2010 at 11:48 PM, Michal Zalewski lcam...@coredump.cx wrote: Can a frame in @sandbox ever navigation the top-level frame? If not, that would make it hard to use @sandbox to contain advertisements, which want to navigate |top| when the user clicks on the ad. Ads would want to be able to do that, but user-controlled gadgets shouldn't. I suppose the top-level page should be able to specify, and the entire @sandbox chain would need to be traversed to make the call (so that @sandbox included on example.com that is prohibited from messing with the top-level frame can't just create a nested frame without the restriction, and bypass the check). I assume that chain-style checking is already a part of the spec, as we obviously don't want other restrictions to be removed in a similar manner? Yes, the sandbox restrictions collect in subframes. Perhaps we want an allow-frame-busting directive? In the implementation we have an allow-navigation bit that covers navigation |top| as well as window.open, etc. Maybe we want a more general directive that twiddles this bit? Some may want to have a directive that allows only opening new windows and not navigating the top level. This is the policy Caja tries to enforce by default for instance. For ads I could imagine wanting only top-level navigation and not window opening. So maybe this should be two flags. Reards, Maciej
Re: [whatwg] @sandbox and navigation top
Can a frame in @sandbox ever navigation the top-level frame? If not, that would make it hard to use @sandbox to contain advertisements, which want to navigate |top| when the user clicks on the ad. Ads would want to be able to do that, but user-controlled gadgets shouldn't. I suppose the top-level page should be able to specify, and the entire @sandbox chain would need to be traversed to make the call (so that @sandbox included on example.com that is prohibited from messing with the top-level frame can't just create a nested frame without the restriction, and bypass the check). I assume that chain-style checking is already a part of the spec, as we obviously don't want other restrictions to be removed in a similar manner? /mz
Re: [whatwg] @sandbox and navigation top
On Fri, Feb 12, 2010 at 11:48 PM, Michal Zalewski lcam...@coredump.cx wrote: Can a frame in @sandbox ever navigation the top-level frame? If not, that would make it hard to use @sandbox to contain advertisements, which want to navigate |top| when the user clicks on the ad. Ads would want to be able to do that, but user-controlled gadgets shouldn't. I suppose the top-level page should be able to specify, and the entire @sandbox chain would need to be traversed to make the call (so that @sandbox included on example.com that is prohibited from messing with the top-level frame can't just create a nested frame without the restriction, and bypass the check). I assume that chain-style checking is already a part of the spec, as we obviously don't want other restrictions to be removed in a similar manner? Yes, the sandbox restrictions collect in subframes. Perhaps we want an allow-frame-busting directive? In the implementation we have an allow-navigation bit that covers navigation |top| as well as window.open, etc. Maybe we want a more general directive that twiddles this bit? Adam
