lgtm
Thanks, Boris!
On Jun 16, 2015 18:16, "Boris Zbarsky" <bzba...@mit.edu> wrote:
>
> On 6/16/15 4:22 AM, Mike West wrote:
>>
>> 2. Sandboxed frames persist their sandboxedness to newly spawned
>> windows, which forces the same restrictive flags upon a landing page.
>
>
> So the reason this behavior is in place is to prevent the sandboxed page from just doing window.open(location.href) and getting itself unsandboxed, right?
>
> Why is that not a problem in the particular case where you envision the "allow-unsandboxed-auxiliary" flag being used?
It would be a problem if we were changing the default behavior. I think it's less of a problem if the embedder is explicitly opting-into the new behavior, based on its knowledge of what it's embedding.
In particular, with this feature, it seems likely that third-party widget providers and advertisers could allow themselves to be sandboxed in various ways (certainly without 'allow-top-navigation', possibly without 'allow-same-origin'), which I think is a use case worth supporting. It trades off a bit of the sandbox's protection for a bit of flexibility, and that flexibility seems essential to certain categories of content that I'd like to see sandboxed.
>> Browsers that support sandboxing but don't support this feature will be
>> a bit of a problem
>
>
> Where "this feature" is "allow-unsandboxed-auxiliary", I assume, since "allow-modals" is already the default behavior in UAs?
Correct. I expect Google's malvertising team to sandbox based on sniffing, for instance, as browsers that don't support the auxiliary behavior won't be usable. I've had spelling out a feature detection mechanism on my list for a little while, and I'd certainly appreciate suggestions.
-mike
One difference is that assigning to window.top.location doesn't require a user gesture. In Chrome (and, I believe, in Firefox? I have no idea how your pop-up blocker works, unfortunately...) it does. I'm much less concerned about the ad navigating the user somewhere interesting after an interaction than I am about the ad maliciously moving the user without any context.
-mike
On Jun 17, 2015 15:59, "Boris Zbarsky" <bzba...@mit.edu> wrote:
>
> On 6/17/15 3:25 AM, Mike West wrote:
>>
>> I don't have a terribly strong opinion about the name, but I'd claim
>> that "unsandboxed-auxiliary" is clearer than "sandbox-escape" with
>> regard to the fact that we're limiting the escape mechanism to whatever
>> can be rendered in a new window.
>
>
> While true, this does not properly represent the security impact, which really is identical to just escaping the sandbox.
"unsandboxed" sounds to me like it communicates the risk.
If it's not clear enough, would just "allow-sandbox-escape" be enough, or is the gesture bit important enough to stuff into the keyword? I guess tacking "-via-gesture" wouldn't be terrible. *shrug*
I guess one worry I have is that if we make the keyword too broad, we won't have good arguments against keeping the mechanisms limited. Scoping the escape to a new window (which is both visible to users and requires a gesture) seems like a less risky proposition than allowing a gesture to navigate the window, for example. In theory, users see new windows. :)
> This works if the sandboxed thing is also not allow-same-origin, I think. If it is, it can just hand the window to the newly opened thing.
>
> How feasible would it be to both disown the opener _and_ have the window.open call return null?
Totally feasible, and, I think, sensible.
-mike
I think we should make window.open return null, disown the owner, and made the new window not targetable by name from the sandboxed thing (at least in the cases when not allow-same-origin, if not always). Given that, having a name that explicitly talks about unsandboxed auxiliarys seems ok to me.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Also, is it possible to get this written into a draft spec now?
On Wed, Jun 17, 2015 at 9:02 AM, Boris Zbarsky <bzba...@mit.edu> wrote:On 6/17/15 11:56 AM, Mike West wrote:
* The name passed into `window.open` will always be interpreted as
"_blank" (which seems simpler than defining a mechanism of blocking
named references).
Hmm. Maybe that's enough. The thing being opened can still set window.name on itself, but you can't use that to target it, I guess, if you force the name arg of window.open to _blank and do likewise with the @target of <a> elements.
Seems reasonable to me.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Tue, Jun 23, 2015 at 12:12 PM, 'Mike West' via blink-dev <blin...@chromium.org> wrote:Talking again with the ads folks, this proposal would remove their ability to determine whether or not a window was indeed opened (as opposed to being blocked by the popup blocker, etc). How would you feel about returning `true` for a window that was opened successfully, but whose handle has been neutered?That would allow code like `if (win) { /* report success! */ }` to operate correctly, while maintaining the invariants we've discussed here. I've specced it out like this on the wiki, as it seems like a reasonable compromise.
Sometimes returning a boolean and sometimes returning a Window sounds pretty bad and hacky to me.
You can return a Window with cross origin conventions (meaning, as if you opened a window from a different origin).It can be null if it were not successfully open and you can even still postMessage to it, but not access anything else (and not have it access anything from your window as well. Well, other than changing location.href? :|).
Since you wrote -> Note that they were a bit bummed that they wouldn't have a messaging channel between the frame and the window, which makes it more difficult to do some interesting things in the future with regard to monitoring, but it sounds like they'd be willing to drop that requirement and come back to it in the future when they have clear use cases. It wouldn't break anything today.I thought that postMessage would actually be a good addition.
Anyway, if you prefer 2, this is fine, but not by messing with the return value type of the ageless window.open. I do not recall any recent API that behave this way, only legacy ones (document.all["non-unique-name-or-id"] versus document.all["unique-name-or-id"]I do not have an alternative, but this one sounds horrible.
On Tue, Jun 23, 2015 at 3:08 PM, PhistucK <phis...@gmail.com> wrote:Since you wrote -> Note that they were a bit bummed that they wouldn't have a messaging channel between the frame and the window, which makes it more difficult to do some interesting things in the future with regard to monitoring, but it sounds like they'd be willing to drop that requirement and come back to it in the future when they have clear use cases. It wouldn't break anything today.I thought that postMessage would actually be a good addition.The ads folks I'm talking to agree with you, though they don't have any direct use for the channel right now. Until such time as they're actually using the channel for something, I don't think there's any particular reason to offer it, given the concerns Boris raised earlier. Not providing it allows us to narrow the scope of the escape significantly, which is valuable.
Anyway, if you prefer 2, this is fine, but not by messing with the return value type of the ageless window.open. I do not recall any recent API that behave this way, only legacy ones (document.all["non-unique-name-or-id"] versus document.all["unique-name-or-id"]I do not have an alternative, but this one sounds horrible.Again, I welcome alternative suggestions.I'm less concerned about the ugliness, given that this _only_ effects `window.open` inside the context of a sandboxed iframe using the newly proposed `allow-sandboxed-auxiliary` keyword. It has zero impact on legacy content.
# Contact emails# SpecJust mailing list conversation at https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0035.html. I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28817 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=28818 to more formally request addition to HTML.This seems a bit too small to poke the TAG about, but I'm happy to do so if there's interest.# SummaryFolks from Google's anti-malvertising team would like to start experimenting with rendering ads in sandboxed iframes in order to mitigate some of the risks to both publishers and users. They've flagged two things blocking the current implementation:1. Modal dialogs cannot be suppressed (and are often used to confuse users).
2. Sandboxed frames persist their sandboxedness to newly spawned windows, which forces the same restrictive flags upon a landing page.
The latter is critical to their use-case, the former is simply super nice-to-have.# Link to "Intent to Implement"`allow-unsandboxed-auxiliary`: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/sandbox/blink-dev/ZOhUntjhc94/EEXYKs9k1bgJ`allow-modals`: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/sandbox/blink-dev/mXX0AO6Lioo/ual1B_3IqTYJ# Demo link# DebuggabillityBrowsers that support sandboxing but don't support this feature will be a bit of a problem, as there's no clear way to feature-detect sandboxing characteristics of a browser. Until such a thing exists, web developers would almost certainly need to resort to UA sniffing, which is fairly ugly.This is an existing problem with `sandbox`, however; I think we could probably expose some sort of "active" set of sandbox flags either on the iframe element, or on a Document, but I would suggest that we can layer something along those lines on later.# Compatibility riskWith the caveat that these numbers are dev-channel only: Over the past week, ~0.003% of documents viewed were sandboxed. ~0.0004% of _those_ generated a modal dialog. I suspect that those numbers will be higher in stable, but they should remain low given the low number of sandboxed documents in general. I'd would also posit that this is a behavior we'd like to make opt-in regardless of usage.With regard to other vendors, the response here on blink-dev has been positive (with the only complaints being that the suggestions don't go far enough in blocking other types of modal dialogs). The response on the WHATWG list was also positive, but hasn't progressed since the initial proposal.I'm CCing some Mozilla folks explicitly in the hopes of soliciting opinions.# OWP Tracking Bug`allow-unsandboxed-auxiliary`: https://crbug.com/487157`allow-modals`: https://crbug.com/483624# Entry on the feature dashboard`allow-unsandboxed-auxiliary`: https://www.chromestatus.com/features/5708368589094912`allow-modals`: https://www.chromestatus.com/features/4747009953103872
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.