Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz dved...@mozilla.com wrote: On Mon, Jul 6, 2015 at 2:47 AM, Mike West mk...@google.com wrote: I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvmentsdiff=9958oldid=9955 It appears that this new keyword as described would still require the use of allow-popups in addition to allow-popups-to-escape-sandbox. Since it doesn't make any sense on its own can you change it so that either keyword allows popups to happen? That it, propose changing [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups keyword. to [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups or *allow-popups-to-escape-sandbox* keyword. (might then require changing -to-escape- to -that-escape-) My only concern with this is that folks might disallow certain sanboxing flags that they know are dangerous, which might mean that their CMS would block `allow-plugins`, but might allow new flags (which would then allow someone to `allow-plugins-to-escape-sandbox`. This kind of blacklisting is probably a bit far fetched, so I could live with the behavior if you feel strongly about it, but I'd prefer to keep the changes as small and additive as possible. -mike
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, Jul 6, 2015 at 2:47 AM, Mike West mk...@google.com wrote: I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvmentsdiff=9958oldid=9955 It appears that this new keyword as described would still require the use of allow-popups in addition to allow-popups-to-escape-sandbox. Since it doesn't make any sense on its own can you change it so that either keyword allows popups to happen? That it, propose changing [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups keyword. to [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups or *allow-popups-to-escape-sandbox* keyword. (might then require changing -to-escape- to -that-escape-) You question to bz was can you live with it, and I can live with it. I wish it could be shorter, but my attempts (allow-popups-unsandboxed or allow-unsandboxed-popups) weren't much shorter. Keeping allow popups in there is good, especially if it can be used in place of regular allow-popups. using the word sandbox is better than anything about auxiliary contexts. - Dan Veditz
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Tue, Jun 23, 2015 at 11:14 AM, Mike West mk...@google.com wrote: After some conversation with bz (CC'd), I've slightly formalized the description of the feature at https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments. This is something that I'd like to ship in Chrome in the somewhat near future. See the Intent to Ship at https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ. Feedback, positive or negative, would be appreciated (either here or there). :) It seems like there's either substantial agreement (or apathy) regarding the `allow-modals` proposal. The auxiliary proposal is the more interesting of the two, and I've revised it again following some more feedback from ads folks. In short, they're more interested in maintaining a communication channel between the sandboxed frame and the auxiliary window than I thought they were. Given that, I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvmentsdiff=9958oldid=9955 . Boris, I think this is consistent with your suggestions in https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ and https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ. Can you live with this naming/behavior? -mike
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On 7/6/15 5:47 AM, Mike West wrote: Boris, I think this is consistent with your suggestions in https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ and https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ. Can you live with this naming/behavior? I personally can probably can... I can't promise anything about how people will respond to an intent to implement for such a thing. -Boris
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, Jul 6, 2015 at 9:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/6/15 5:47 AM, Mike West wrote: Boris, I think this is consistent with your suggestions in https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ and https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ . Can you live with this naming/behavior? I personally can probably can... I can't promise anything about how people will respond to an intent to implement for such a thing. I'll take it. :) -mike
Re: [whatwg] Proposal: Two changes to iframe@sandbox
After some conversation with bz (CC'd), I've slightly formalized the description of the feature at https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments. This is something that I'd like to ship in Chrome in the somewhat near future. See the Intent to Ship at https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ. Feedback, positive or negative, would be appreciated (either here or there). :) -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Sun, May 17, 2015 at 8:59 PM, Mike West mk...@google.com wrote: On Mon, May 11, 2015 at 6:11 AM, Mike West mk...@google.com wrote: 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. This flag is in the latest Chrome Canary, behind chrome://flags/#enable-experimental-web-platform-features, if anyone is interested in playing with the feature. Given the generally positive response on this thread, WDYT about adding it to HTML, hixie@? I'd like to circle back to the `allow-modals` proposal once https://www.chromestatus.com/metrics/feature/timeline/popularity/767 hits stable and starts bringing in reliable data (~12 weeks). I'll ping the thread again then. :) -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 6:11 AM, Mike West mk...@google.com wrote: 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. This flag is in the latest Chrome Canary, behind chrome://flags/#enable-experimental-web-platform-features, if anyone is interested in playing with the feature. Given the generally positive response on this thread, WDYT about adding it to HTML, hixie@? I'd like to circle back to the `allow-modals` proposal once https://www.chromestatus.com/metrics/feature/timeline/popularity/767 hits stable and starts bringing in reliable data (~12 weeks). I'll ping the thread again then. :) -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Thu, May 14, 2015 at 3:59 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. Why isn't a child iframe of the sandboxed iframe an auxiliary browsing context? Because it's a nested browsing context. Auxiliary browsing contexts are related to a context, but not through nesting: https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-contexts. It's just a definitional thing. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 9:19 AM, Jim Manico jim.man...@owasp.org wrote: The whole purpose of a sandbox is to limit what content inside of it can do. I want to limit where that sandbox can open windows with full cookie/script/etc access. And you can do so by _not_ specifying the new flag I'm proposing. :) Again `iframe sandbox`'s behavior would not change. The proposal would add new behavior only for something like `iframe sandbox=allow-unsandboxed-auxiliary allow-popup`. So essentially I want to say, You can show your ad, you cant run a script or access my main window. Also, you can only open full-access windows back to the same domain that your ad came from. If the ad comes from `advertising-is-awesome.net`, but is pointing users to the excellent products at `products-are-nice.com`, how would your proposal allow a click on the ad to navigate a user to the excellent products in an unsandboxed window (e.g. one that has an origin)? I'd suggest that that's an essential component. It's certainly essential to advertisers. Is that to extreme of an ask? I just dont like the idea that a sandboxed resource has full access to open any new window. It seems excessive and can exploit CSRF vulns in a way a full sandboxed iFrame as I'm describing could not. I still don't understand the threat model you're proposing. That is, I don't see sandboxing as a CSRF defense at all. Sandboxed frames can navigate themselves to any origin right now, and load any origin in a frame. If the `allow-popups` flag is set, it can open auxiliary windows. If the `allow-forms` flag is set, it can POST to arbitrary origins. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 4:02 PM, Chris Coyier chriscoy...@gmail.com wrote: I'd think popups would be killed by default and allow-popups would allow them. Or if you need a new value, allow-obnoxious-things could work ;) I would prefer to simply remove the functionality. :) If we do decide that we need `alert()` and friends, I would suggest that `allow-popups` is the wrong flag to use. The advertising use case I noted at the top pretty much requires `window.open`/`target=_blank` to work correctly. If those only work when `alert()` is enabled, then we wouldn't solve the issue. Like navigator.geolocation (so we regex and strip it). I think permissions for iframes in general are a separate question, but an important one to deal with. The worst offender: linking to things that are .htpasswd protected and it pops up that authentication modal. I wouldn't be terribly averse to dropping support for that inside a sandbox. Especially a sandbox without `allow-same-origin`. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
1. Block modal dialogs from inside sandboxed frames. That is: * `alert(...)` would return without popping up a dialog. * `confirm(...)` would return `false` without popping up a dialog. * `prompt(...)` would return `null` without popping up a dialog. * `print(...)` would return without popping up a dialog. I'm OK with that. As a general rule, though, I would prefer that pretty much whatever gets blocked by default can be reenabled via additional new keywords (e.g. allow-modals). Although I understand the rational for blocking native plugins by default due to their inherent unmanaged nature, I still wish that they could be reenabled via a keyword as there are still realistic scenarios where you may want (e.g.) Flash enabled but still disallow/disable other features like popups, navigation, etc. 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. I'm OK with that, too. I'm assuming that cascades, though, right? In other words, if the top window does NOT use the allow-unsandboxed-auxiliary keyword on its child iframe, I'm assuming the child iframe cannot successfully use allow-unsandboxed-auxiliary on a child iframe of its own. Sincerely, James Greene On Sun, May 10, 2015 at 11:11 PM, Mike West mk...@google.com wrote: (BCC: public-webapp...@w3.org) Hello, wonderful whatwg@ folks! I've talked with a few folks from Google's advertising teams who are interested in using sandboxed iframes to mitigate the risks associated with ads. They've flagged two things that they'd like to see happen in the future: 1. Block usage of `alert()` (and its friends `confirm()`, `prompt()`, and `print()` (and `showModalDialog()` for browsers that support it)). 2. Allow sandboxed frames to spawn new windows without forcing the sandbox upon them. This would allow the advertisement itself to be sandboxed, without forcing the same restrictive flags upon a landing page. # Proposal 1. Block modal dialogs from inside sandboxed frames. That is: * `alert(...)` would return without popping up a dialog. * `confirm(...)` would return `false` without popping up a dialog. * `prompt(...)` would return `null` without popping up a dialog. * `print(...)` would return without popping up a dialog. This was discussed briefly at https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html , but I didn't find any follow-up (CCing folks from that thread). I've added metrics to Chrome in https://codereview.chromium.org/1121053002, but it will take a few weeks to get good data. Given the low usage of sandboxes in general (~0.5% of page views, according to https://www.chromestatus.com/metrics/feature/timeline/popularity/672), I suspect we could fairly easily make this change. 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. WDYT? -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 4:12 PM, James M. Greene james.m.gre...@gmail.com wrote: 1. Block modal dialogs from inside sandboxed frames. That is: * `alert(...)` would return without popping up a dialog. * `confirm(...)` would return `false` without popping up a dialog. * `prompt(...)` would return `null` without popping up a dialog. * `print(...)` would return without popping up a dialog. I'm OK with that. As a general rule, though, I would prefer that pretty much whatever gets blocked by default can be reenabled via additional new keywords (e.g. allow-modals). Sure. It's not clear to me that there's a _good_ use of any of these methods in an iframe, so I'd prefer to just remove the capability entirely, but if there's a desire to retain the functionality, I'd certainly implement something like `allow-modals` in Chrome. Although I understand the rational for blocking native plugins by default due to their inherent unmanaged nature, I still wish that they could be reenabled via a keyword as there are still realistic scenarios where you may want (e.g.) Flash enabled but still disallow/disable other features like popups, navigation, etc. An issue with Flash (and other plugins) is that they generally bypass the rest of the sandboxing flags. That is, enabling flash while disabling `window.open` is somewhat ineffectual, as Flash can just pop a new window with it's native code. This is somewhat improved in Chrome, as PPAPI allows us a bit more access to the ways in which Flash can poke at the system, but it doesn't improve the (terrible) process model, etc. I think it would still be a bit too dangerous to introduce an `allow-plugins` flag given the sandboxing state in other browsers, but it's probably a conversation worth having. 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. I'm OK with that, too. I'm assuming that cascades, though, right? In other words, if the top window does NOT use the allow-unsandboxed-auxiliary keyword on its child iframe, I'm assuming the child iframe cannot successfully use allow-unsandboxed-auxiliary on a child iframe of its own. Yes, this is also how I imagined it working. I should have made that clear in the proposal, but I think (hope!) this naturally falls out of the way sandbox flags are propagated from frame to frame/window to window. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 7:13 AM, Mike West mk...@google.com wrote: The worst offender: linking to things that are .htpasswd protected and it pops up that authentication modal. I wouldn't be terribly averse to dropping support for that inside a sandbox. Especially a sandbox without `allow-same-origin`. Firefox sorta does this by default, as of https://bugzilla.mozilla.org/show_bug.cgi?id=647010. At least it appears to for cross-origin iframes, which I would expect to be the normal case for ads? Also, along with blocking alert() et al from sandboxed iframes, it would be good to include the onbeforeunload dialog. It's a pretty common target for abuse. We've got a bug to disable it entirely in iframes (1131187), but no one is actively working on it. Justin
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 7:24 PM, Ian Melven ian.mel...@gmail.com wrote: 1) At one point i think showModalDialog was specified to be blocked unless allow-popups was set. (I can't find this in the current editor's draft of the spec). It seems to me that it would make sense to follow #1 in your proposal (blocking alert and friends) UNLESS allow-popups is specified perhaps ? Unless the advertising use case is such that they would want to specify allow-popups in most common cases, which negates any benefit of this restriction in practice My understanding of the use case is that they want `allow-popups` in order to allow navigation to a landing page via `target=_blank`, et al. They don't want modal dialogs from that same window. Tying both behaviors to `allow-popups` wouldn't solve their problem. 2) this also sounds like allow-popups would be needed (since you shouldn't be allowed to open new auxiliary browsing context without it) Correct. Both `allow-popups` and the new flag would need to be specified. and maybe is more consistent using 'allow-popups-unsandboxed' ? Or `allow-unsandboxed-popups`. I don't really care how we spell it. :) -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 11:59 PM, Justin Dolske dol...@mozilla.com wrote: On Mon, May 11, 2015 at 7:13 AM, Mike West mk...@google.com wrote: The worst offender: linking to things that are .htpasswd protected and it pops up that authentication modal. I wouldn't be terribly averse to dropping support for that inside a sandbox. Especially a sandbox without `allow-same-origin`. Firefox sorta does this by default, as of https://bugzilla.mozilla.org/show_bug.cgi?id=647010. At least it appears to for cross-origin iframes, which I would expect to be the normal case for ads? Interesting! Thanks for the pointer to the bug. If Firefox is already going this route, I don't see any reason Chrome shouldn't follow. It makes sense to me, in any event. Also, along with blocking alert() et al from sandboxed iframes, it would be good to include the onbeforeunload dialog. It's a pretty common target for abuse. We've got a bug to disable it entirely in iframes (1131187), but no one is actively working on it. Ah, yes. I forgot about `onbeforeunload`. I'd happily kill that inside a sandbox as well. :) -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Mon, May 11, 2015 at 7:27 AM, Jim Manico jim.man...@owasp.org wrote: 2. Allow sandboxed frames to spawn new windows without forcing the sandbox upon them. I think this needs to be restricted so sandboxed iFrames cannot spawn new windows back to the same domain - or better yet may only spawn windows to limited domain/domains driven by the initial ad request. What risk do you see that mitigating? How would you expect it to behave with regard to redirects or navigations? I guess I don't see the value in adding these kinds of restrictions, and (especially given the target audience, and their predilection for tons and tons of cross-origin redirects) it seems like making it easier to sandbox the inlined frame outweighs the desire to lock down the out-of-line auxiliary browsing context. Also, note that the proposal already makes the behavior opt-in via the `allow-unsandboxed-auxiliary` keyword (it wouldn't change the behavior of any existing sandboxed frame), and browsers generally throttle the creation of popups in various ways (Chrome allows only one popup per user gesture, for instance). -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
[whatwg] Proposal: Two changes to iframe@sandbox
(BCC: public-webapp...@w3.org) Hello, wonderful whatwg@ folks! I've talked with a few folks from Google's advertising teams who are interested in using sandboxed iframes to mitigate the risks associated with ads. They've flagged two things that they'd like to see happen in the future: 1. Block usage of `alert()` (and its friends `confirm()`, `prompt()`, and `print()` (and `showModalDialog()` for browsers that support it)). 2. Allow sandboxed frames to spawn new windows without forcing the sandbox upon them. This would allow the advertisement itself to be sandboxed, without forcing the same restrictive flags upon a landing page. # Proposal 1. Block modal dialogs from inside sandboxed frames. That is: * `alert(...)` would return without popping up a dialog. * `confirm(...)` would return `false` without popping up a dialog. * `prompt(...)` would return `null` without popping up a dialog. * `print(...)` would return without popping up a dialog. This was discussed briefly at https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html, but I didn't find any follow-up (CCing folks from that thread). I've added metrics to Chrome in https://codereview.chromium.org/1121053002, but it will take a few weeks to get good data. Given the low usage of sandboxes in general (~0.5% of page views, according to https://www.chromestatus.com/metrics/feature/timeline/popularity/672), I suspect we could fairly easily make this change. 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. WDYT? -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
