Intent to Implement: 'allow-unsandboxed-auxiliary' sandbox flag.

48 views
Skip to first unread message

Mike West

unread,
May 12, 2015, 6:59:30 AM5/12/15
to blink-dev
# Contact emails
mk...@chromium.org

# Spec
Just mailing list conversation at https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0035.html; I'm hopeful we can get it into HTML if folks think it's a reasonable addition.

# Summary
This is a new flag for `<iframe sandbox="...">` which will allow a sandboxed document to spawn new windows without forcing the sandboxing flags upon them. This will allow, for example, a third-party advertisement to be safely sandboxed without forcing the same restrictions upon a landing page. 

# Motivation
Folks in Google's anti-malvertising team would like to begin sandboxing the iframes in which ads are embedded. In some cases, this can be truly restrictive, in others they'd enable basically everything except `allow-top-navigation`. Their experiments thus far have been blocked on sandboxing's inheritance structure: there's no way to open an unsandboxed window from inside a sandbox, which means that a sandboxed advertisement leads to a sandboxed landing page, and so on.

Sites like CodePen have similar desires (as noted at the bottom of https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0057.html): limit the impact of unknown content by sandboxing it, but allow it to spawn unsandboxed browsing contexts for navigation.

This seems like a reasonable thing to allow an embedder to opt-out of, and adding a new flag to enable otherwise limited functionality is consistent with the rest of `sandbox`.

# Compatibility Risk
Firefox: No public signals
Internet Explorer: No public signals
Safari: No public signals
Web developers: Positive

# Describe the degree of compatibility risk you believe this change poses
Browsers 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.

Suggestions regarding detection possibilities are welcome. :)

# Ongoing technical constraints
None.

# Will this feature be supported on all six Blink platforms
Yes.

# OWP launch tracking bug

# Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5708368589094912

# Requesting approval to ship?
No.

-mike

Chris Harrelson

unread,
May 13, 2015, 2:56:40 AM5/13/15
to Mike West, blink-dev
Not necessary, but LGTM anyway.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Jägenstedt

unread,
May 13, 2015, 6:19:39 AM5/13/15
to Chris Harrelson, Mike West, blink-dev
Sounds like a plan, LGTM.
Reply all
Reply to author
Forward
0 new messages