-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sandbox
attribute to <object>
element
#2514
Comments
@AmeliaBR it seems better to get to the bottom of those inconsistencies and fix those. Do you have web-platform-tests?
|
SVG is a special case because However, even for Flash or PDF or other plug-in object, some of the sandbox restrictions (e.g., top-level navigation, pointer-lock, full-screen) could be enforced by the browser. It seems strange not to have that option, except by nesting the |
That would only make sense if folks are still investing in plugin architecture and if plugin architecture was standardized. Neither of those is the case so any such effort would be in vain. |
I believe Flash does not support sandbox restrictions. So the only way to make sure Flash does not escape your sandbox is to disallow Flash from running in the first place. Not sure what the situation is like for PDF. |
Is there any reason that
<object>
(and<embed>
) was not included when adding thesandbox
attribute? There's a lot of text in the spec about restricting objects that are themselves in a sandboxed browsing context, but no way to specifically sandbox the object document or object plug-in.My personal use case is for SVG objects. Although you can now embed SVG with
<iframe>
pretty much everywhere, the scaling and sizing is different than an<object>
in most browsers, and is inconsistent from browser to browser. Right now, the only reasons I'd recommend using<iframe>
for SVG are sandboxing and getting browsing-context names to work in IE/Edge.The text was updated successfully, but these errors were encountered: