Re: [whatwg] `iframe[@sandbox]`: "sandblaster" JS library for analysis/modification
On Wed, Sep 30, 2015 at 10:51 AM, Mike West <mk...@google.com> wrote: > On Wed, Sep 30, 2015 at 4:56 PM, James M. Greene <james.m.gre...@gmail.com > > wrote: >> >> *and* potentially modifying/dismantling >> iframe sandboxes. >> > > Are you able to do this in any cases other than `allow-same-origin` and > `allow-scripts`? If so, we should fix them. :) > I haven't spotted any such holes, though I also haven't tested it in all of the various browser/OS configurations. Again, you can see the live analysis results for your browser at http://jamesmgreene.github.io/sandblaster/test-iframes.html :) > Thanks for putting this together! > Welcomed! It was an interesting learning experience for me. Sincerely, James Greene
[whatwg] `iframe[@sandbox]`: "sandblaster" JS library for analysis/modification
*I should've shared this a long time ago but better late than never* Last winter, I was dealing with some confusion surrounding `iframe` sandboxing [when I wasn't aware it existed] on code playground sites (JSFiddle, JSBin, CodePen, etc.). While investigating, I ended up creating a JS library called *sandblaster* [1] to assist me in analyzing *and* potentially modifying/dismantling iframe sandboxes. You can see a live analysis result example on its demo page [2]. Please check it out if you're interested in the subject and feel free to contribute issues/PRs/tests/suggestions/etc. on its GitHub repo [1]. Thanks! [1]: https://github.com/JamesMGreene/sandblaster [2]: http://jamesmgreene.github.io/sandblaster/test-iframes.html Sincerely, James Greene
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] Supporting feature tests of untestable features
We had it but browser cendors abandoned its proper behavior [for some
historical reason unbeknownst to me]
DOMImplementation.hasFeature (document.hasFeature):
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-5CED94D7
and
Node.isSupported:
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Level-2-Core-Node-supports
We are running into the exact same issues with the HTML Clipboard API being
unreliably detectable. Even more troubling, this is especially true because
it is already partially supported (paste events) in some browsers (e.g.
Chrome), not at all supported in others, and fully supported in none.
Sincerely,
James M. Greene
On Apr 1, 2015 3:36 AM, Roger Hågensen rh_wha...@skuldwyrm.no wrote:
On 2015-04-01 06:57, Kyle Simpson wrote:
There are features being added to the DOM/web platform, or at least under
consideration, that do not have reasonable feature tests obvious/practical
in their design. I consider this a problem, because all features which
authors (especially those of libraries, like me) rely on should be able to
be tested if present, and fallback if not present.
Paul Irish did a round-up awhile back of so called undetectables here:
https://github.com/Modernizr/Modernizr/wiki/Undetectables
I don't want to get off topic in the weeds and/or invite bikeshedding
about individual hard to test features. So I just want to keep this
discussion to a narrow request:
Can we add something like a feature test API (whatever it's called)
where certain hard cases can be exposed as tests in some way?
The main motivation for starting this thread is the new `link
rel=preload` feature as described here: https://github.com/w3c/preload
Specifically, in this issue thread: https://github.com/w3c/
preload/issues/7 I bring up the need for that feature to be testable,
and observe that as currently designed, no such test is feasable. I believe
that must be addressed, and it was suggested that perhaps a more general
solution could be devised if we bring this to a wider discussion audience.
A featurecheck API? THat sort of makes sense.
I see two ways to do this.
One would be to call a function like (the fictional) featureversion()
and get back a version indicating that the browser support the ECMA
something standard as a bare minimum. But version checking is something I
try to avoid even when doing programming on Windows (and MicroSoft advise
against doing it).
So a better way might be:
featexist('function','eval')
featexist('document','link','rel','preload')
featexist('api','websocket')
Yeah the preload example does not look that pretty but hopefully you know
what I'm getting at here. Maybe featexist('html','link','preload')
instead?
On Windows programs I try to always dynamically load a library and then I
get a function pointer to a named function, if it fails then I know the
function does not exist in that dll and I can either fail gracefully or
provide alternative code to emulate the missing function.
It's thanks to this that on streaming audio player I made axctually works
on anything from Windows 2000 up to WIndows 8.1 and dynamically makes use
of new features in more recent Windows versions thanks to being able to
check if functions actually exists.
I use the same philosophy when doing Javascript and HTML5 coding.
With the featexist() above true is returned if present and false if not
present.
Now what to do if eval() does not exist as a pre-defined function but a
user defined eval() function exists instead for some reason.
My suggestion is that featexist() should return false in that case as it
is not a function provided by the browser/client.
Now obviously a|if (typeof featexist == 'function')| would have to be
done before calling featexist() and there is no way to get around that.
Another suggestion is that if a feature is disabled (by the user, the
admin or the browser/client for some reason) ten featexist() should behave
as if that feature does not existis not supported.
In other words featexist() could be a simple way to ask the browser if
is this available? can I use this right now?
--
Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Supporting feature tests of untestable features
P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste/etc events, which could likewise be detectable with on* attributes. Am I missing something else that is not detectable for fundamental reasons? Not to side-track this generalized conversation too much but it may actually be useful to detail the state of Clipboard API detection here based on current practices and APIs (which is completely hopeless): *Event-based detection:* The onbeforecopy, onbeforecut, onbeforepaste, oncopy, oncut, and onpaste events have all existed in IE, Safari, and Chrome (and now modern Opera, I'd imagine) for quite some time, related to standard user actions for copy/cut/paste (and more importantly for ContentEditable purposes, IIRC). So this approach would return false positives for at least every modern major browser other than Firefox (if not Firefox, too). *Method-based detection:* Firefox, for example, implements `clipboardData.setData()`/`clipboardData.getData()` and also implements the `ClipboardEvent` constructor, does not actually modify the user's clipboard on `clipboard.setData()`. Additionally, to even get access to `clipboardData`, you must be able to synthetically execute one of these commands (e.g. copy). So this approach isn't great, and will return false positives for Firefox anyway. *Command-based detection:* Since the actual actions like copy, etc. will be triggered via ye olde query commands (i.e. `document.execCommand`), another proper approach for detection would be using the `document.queryCommandSupported` and `document.queryCommandEnabled` methods to check for support. However, those methods work inconsistently cross-browser, some throw Errors instead of returning `false`, etc. Beside all that, the copy, cut, and paste query commands have all previously existed for ContentEditable purposes. So this approach is flawed, unreliable, and will return false positives. *Implementation-based detection:* As previously discussed in this thread, `document.implementation.hasFeature` and/or `Node.isSupported` could have been another idea for feature detection but has already been bastardized to the point of no return. So this approach, if implemented, would almost always return false positives (e.g. Firefox, if not all other browsers, returns `true` for everything). As far as checking on full implementations, it would be nice if specs followed some reliable versioning pattern like SemVer that we could use to verify the correct level of support. Even at that point, though: should such an approach only check against W3C specs or also WHATWG specs? Additionally, as you mentioned, it would be much better if we could create some API which would offer the ability to check for partial implementations (features/sub-features) vs. full spec implementations as well. For example, Chrome has implemented the paste feature of the Clipboard API nearly completely but has NOT implemented the copy or cut features. Sincerely, James Greene On Wed, Apr 1, 2015 at 8:07 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/1/15 8:27 AM, James M. Greene wrote: We had it but browser cendors abandoned its proper behavior [for some historical reason unbeknownst to me] The support signal (the hasFeature() implementation) was not in any way coupled with the actual implementation. So you would have cases in which hasFeature() claimed false even though the browser supported the feature, cases in which hasFeature() claimed true even though the browser didn't support the feature, and cases in which the browser had somewhat rudimentary support for the feature but hasFeature() claimed true because of various market pressures. This was especially driven by the coarse nature of the features involved -- you could at best ask questions like is this spec supported?, not is this particular piece of functionality supported?. That works OK for small targeted specs, but the W3C wasn't so much in the business of doing those. The upshot was that in any sort of interesting case hasFeature was useless at best and misleading at worst. We are running into the exact same issues with the HTML Clipboard API being unreliably detectable. Even more troubling, this is especially true because it is already partially supported (paste events) in some browsers (e.g. Chrome), not at all supported in others, and fully supported in none. So let's consider this case. How would a hasFeature deal with this situation? At what point would you expect it to start returning true for the clipboard API? -Boris P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste
Re: [whatwg] Supporting feature tests of untestable features
P.S. If you want to get involved, here is a link to the archive of the most recent email thread about feature detection for the Clipboard API: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0592.html Sincerely, James Greene On Wed, Apr 1, 2015 at 9:04 AM, James M. Greene james.m.gre...@gmail.com wrote: P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste/etc events, which could likewise be detectable with on* attributes. Am I missing something else that is not detectable for fundamental reasons? Not to side-track this generalized conversation too much but it may actually be useful to detail the state of Clipboard API detection here based on current practices and APIs (which is completely hopeless): *Event-based detection:* The onbeforecopy, onbeforecut, onbeforepaste, oncopy, oncut, and onpaste events have all existed in IE, Safari, and Chrome (and now modern Opera, I'd imagine) for quite some time, related to standard user actions for copy/cut/paste (and more importantly for ContentEditable purposes, IIRC). So this approach would return false positives for at least every modern major browser other than Firefox (if not Firefox, too). *Method-based detection:* Firefox, for example, implements `clipboardData.setData()`/`clipboardData.getData()` and also implements the `ClipboardEvent` constructor, does not actually modify the user's clipboard on `clipboard.setData()`. Additionally, to even get access to `clipboardData`, you must be able to synthetically execute one of these commands (e.g. copy). So this approach isn't great, and will return false positives for Firefox anyway. *Command-based detection:* Since the actual actions like copy, etc. will be triggered via ye olde query commands (i.e. `document.execCommand`), another proper approach for detection would be using the `document.queryCommandSupported` and `document.queryCommandEnabled` methods to check for support. However, those methods work inconsistently cross-browser, some throw Errors instead of returning `false`, etc. Beside all that, the copy, cut, and paste query commands have all previously existed for ContentEditable purposes. So this approach is flawed, unreliable, and will return false positives. *Implementation-based detection:* As previously discussed in this thread, `document.implementation.hasFeature` and/or `Node.isSupported` could have been another idea for feature detection but has already been bastardized to the point of no return. So this approach, if implemented, would almost always return false positives (e.g. Firefox, if not all other browsers, returns `true` for everything). As far as checking on full implementations, it would be nice if specs followed some reliable versioning pattern like SemVer that we could use to verify the correct level of support. Even at that point, though: should such an approach only check against W3C specs or also WHATWG specs? Additionally, as you mentioned, it would be much better if we could create some API which would offer the ability to check for partial implementations (features/sub-features) vs. full spec implementations as well. For example, Chrome has implemented the paste feature of the Clipboard API nearly completely but has NOT implemented the copy or cut features. Sincerely, James Greene On Wed, Apr 1, 2015 at 8:07 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/1/15 8:27 AM, James M. Greene wrote: We had it but browser cendors abandoned its proper behavior [for some historical reason unbeknownst to me] The support signal (the hasFeature() implementation) was not in any way coupled with the actual implementation. So you would have cases in which hasFeature() claimed false even though the browser supported the feature, cases in which hasFeature() claimed true even though the browser didn't support the feature, and cases in which the browser had somewhat rudimentary support for the feature but hasFeature() claimed true because of various market pressures. This was especially driven by the coarse nature of the features involved -- you could at best ask questions like is this spec supported?, not is this particular piece of functionality supported?. That works OK for small targeted specs, but the W3C wasn't so much in the business of doing those. The upshot was that in any sort of interesting case hasFeature was useless at best and misleading at worst. We are running into the exact same issues with the HTML Clipboard API being unreliably detectable. Even more troubling, this is especially true because it is already partially supported (paste events) in some browsers (e.g. Chrome), not at all supported in others, and fully supported in none. So let's consider this case
Re: [whatwg] Unicode - ASCII copy/paste fallback
In this case, you can use Unicode escape values by preceding them with a
slash:
.rarr:after { content: \2192; }
This is specified in the CSS 2.1 spec:
http://www.w3.org/TR/CSS2/syndata.html#characters
Personally, I probably would've just started on StackOverflow with this
question (e.g. [1]) but no harm done.
[1]:
http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value
Sincerely,
James Greene
On Fri, Feb 13, 2015 at 5:45 AM, David Sheets kosmo...@gmail.com wrote:
Hello,
I have a page with
a span class=rarrspan-gt;/span/span b
and style
.rarr span { overflow: hidden; height: 0; width: 0; display: inline-block;
}
.rarr::after { content: →; }
(That's RIGHTWARDS ARROW x2192.)
In Firefox 36, this copies and pastes like a - b which is the
desired behavior. In Chrome 40, this copies and pastes like a b.
Is my desired behavior (to show unicode but copy an ASCII
representation) generally possible? Are there specs somewhere about
copy/paste behavior? I looked in https://html.spec.whatwg.org/ but
found nothing relevant.
Is this the right venue for this question? Should I take it somewhere else?
Thanks,
David Sheets
Re: [whatwg] Unicode - ASCII copy/paste fallback
Sorry, David Mathias. Hasty 6:00am reply here before my brain and eyes
fully woke up!
Interesting question. Personally, I would expect and desire the
CSS-generated content to be copied.
Sincerely,
James M. Greene
On Feb 13, 2015 6:24 AM, David Sheets kosmo...@gmail.com wrote:
On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
james.m.gre...@gmail.com wrote:
In this case, you can use Unicode escape values by preceding them with a
slash:
.rarr:after { content: \2192; }
This is specified in the CSS 2.1 spec:
http://www.w3.org/TR/CSS2/syndata.html#characters
Personally, I probably would've just started on StackOverflow with this
question (e.g. [1]) but no harm done.
Hi James!
Sorry, I wasn't clear. The issue is not with putting Unicode values
into CSS. The issue is that I would like unicode values to be copied
and pasted as a specific ASCII fallback value.
That is, I would like the equivalent of a rarr; b to appear on a
page but, upon copying, a - b to show up in the clipboard.
I have a solution that works in Firefox 36 (described in original
mail). Chrome 40 does not behave similarly.
I can see some arguments for Chrome's behavior along security lines. I
certainly can understand the utility of Firefox's behavior because I
am writing a documentation generation tool for a programming language
with right arrows represented as - but would like to render them as
→.
This seems like a pretty straightforward document feature but I can't
seem to get interoperable behavior (or even find where such behavior
might be specified).
Thanks,
David
[1]:
http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value
Sincerely,
James Greene
On Fri, Feb 13, 2015 at 5:45 AM, David Sheets kosmo...@gmail.com
wrote:
Hello,
I have a page with
a span class=rarrspan-gt;/span/span b
and style
.rarr span { overflow: hidden; height: 0; width: 0; display:
inline-block;
}
.rarr::after { content: →; }
(That's RIGHTWARDS ARROW x2192.)
In Firefox 36, this copies and pastes like a - b which is the
desired behavior. In Chrome 40, this copies and pastes like a b.
Is my desired behavior (to show unicode but copy an ASCII
representation) generally possible? Are there specs somewhere about
copy/paste behavior? I looked in https://html.spec.whatwg.org/ but
found nothing relevant.
Is this the right venue for this question? Should I take it somewhere
else?
Thanks,
David Sheets
Re: [whatwg] Unicode - ASCII copy/paste fallback
To expand on my own comment:
Personally, I would expect and desire the CSS-generated content to be
copied.
...because THAT is what the user sees, per the browser rendering. I'm
surprised that neither Firefox nor Chrome exhibits that behavior.
Sincerely,
James M. Greene
On Feb 13, 2015 6:30 AM, James M. Greene james.m.gre...@gmail.com wrote:
Sorry, David Mathias. Hasty 6:00am reply here before my brain and eyes
fully woke up!
Interesting question. Personally, I would expect and desire the
CSS-generated content to be copied.
Sincerely,
James M. Greene
On Feb 13, 2015 6:24 AM, David Sheets kosmo...@gmail.com wrote:
On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
james.m.gre...@gmail.com wrote:
In this case, you can use Unicode escape values by preceding them with a
slash:
.rarr:after { content: \2192; }
This is specified in the CSS 2.1 spec:
http://www.w3.org/TR/CSS2/syndata.html#characters
Personally, I probably would've just started on StackOverflow with this
question (e.g. [1]) but no harm done.
Hi James!
Sorry, I wasn't clear. The issue is not with putting Unicode values
into CSS. The issue is that I would like unicode values to be copied
and pasted as a specific ASCII fallback value.
That is, I would like the equivalent of a rarr; b to appear on a
page but, upon copying, a - b to show up in the clipboard.
I have a solution that works in Firefox 36 (described in original
mail). Chrome 40 does not behave similarly.
I can see some arguments for Chrome's behavior along security lines. I
certainly can understand the utility of Firefox's behavior because I
am writing a documentation generation tool for a programming language
with right arrows represented as - but would like to render them as
→.
This seems like a pretty straightforward document feature but I can't
seem to get interoperable behavior (or even find where such behavior
might be specified).
Thanks,
David
[1]:
http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value
Sincerely,
James Greene
On Fri, Feb 13, 2015 at 5:45 AM, David Sheets kosmo...@gmail.com
wrote:
Hello,
I have a page with
a span class=rarrspan-gt;/span/span b
and style
.rarr span { overflow: hidden; height: 0; width: 0; display:
inline-block;
}
.rarr::after { content: →; }
(That's RIGHTWARDS ARROW x2192.)
In Firefox 36, this copies and pastes like a - b which is the
desired behavior. In Chrome 40, this copies and pastes like a b.
Is my desired behavior (to show unicode but copy an ASCII
representation) generally possible? Are there specs somewhere about
copy/paste behavior? I looked in https://html.spec.whatwg.org/ but
found nothing relevant.
Is this the right venue for this question? Should I take it somewhere
else?
Thanks,
David Sheets
Re: [whatwg] Confusion about node1.replace(node2)
I have to agree with Glen on this one. Using `node1.replace(node2);` makes me expect that `node1` will be replacing by `node2`. jQuery is famous (and sometimes infamous, depending on who you talk to) for its API brevity and yet we still chose longer names[1] for these scenarios: `replaceWith` and `replaceAll` (even including All in the latter to clarify that it operates on the entire context set, not just the first element). Dojo uses the same method names[2] as well for their NodeList implementation: `replaceWith` and `replaceAll`. If not renamed, `ChildNode#replace` will probably need to be added to my personal list DOM APIs that I'm always doubtful of how to use despite years of off-and on usage... along with, e.g. `ParentNode#insertBefore` and `ParentNode#insertAfter` for their parameter order. [1]: http://api.jquery.com/category/manipulation/dom-replacement/ [2]: http://dojotoolkit.org/api/1.10/dojo/NodeList.html Sincerely, James Greene On Jan 10, 2015 3:56 AM, Glen Huang curvedm...@gmail.com wrote: And since methods operate on the object they are invoked upon I think the name is clear enough. The fact replace() is a method operating on an object doesn’t clarify the intention in this case,because the confusion here is that it’s unclear whether the object is having others take its place, or is itself trying take others’ place, and from the general meaning of the english word “replace”, it actually implies the latter. The general preference is brevity over precision. In most cases, I favor brevity too, but when it starts to raise confusion, especially it’s implying the opposite of what it’s actually trying to do, brevity should no longer be a priority, IMHO.
Re: [whatwg] Clarification for window.opener.location.href
Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. The spec doesn't mention that `rel=nofollow` should null out `window.opener`. That behavior is only mentioned for `rel=noreferrer`. http://www.w3.org/TR/html5/links.html#link-type-nofollow http://www.w3.org/TR/html5/links.html#link-type-noreferrer http://www.w3.org/TR/html5/browsers.html#noopener (only specifically mentions noreferrer) https://html.spec.whatwg.org/#link-type-nofollow https://html.spec.whatwg.org/#link-type-noreferrer https://html.spec.whatwg.org/#noopener (only specifically mentions noreferrer) Sincerely, James Greene On Tue, Jan 6, 2015 at 2:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/15 3:10 PM, Nicholas C. Zakas wrote: Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. Browser support there is still spotty but improving. Of course that affects more than just window.opener (e.g. affects whether a referrer is sent) -Boris
[whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
I have recently begun receiving issue reports about my JavaScript library, ZeroClipboard, not working in some common developer websites such as JSFiddle, CodePen, etc. The common thread here is that the problematic sites all host their snippets within sandboxed iframes... but ZeroClipboard relies on a seamless integration of a small Flash object. I eventually tracked this back to the iframe's `sandbox` attribute not allowing plugins to be instantiated [1] due the always-on sandboxed plugin browsing context [2]. When reviewing the HTML spec on both W3C and WHATWG, I found that this is *supposedly* not 100% accurate as there is a *suggestion* that a plugin can *somehow* identify itself as *secured* and thus still be allowed to instantiate within a sandboxed iframe [3][4][5]. However, from practical experience, I also believe that none of today's existing browser vendor implementations of iframe sandboxing take such a concept into consideration. From [5]: A plugin can be *secured* if it honors the semantics of the sandbox attribute. *For example, a secured plugin would prevent its contents from creating pop-up windows when the plugin is instantiated inside a sandboxed iframe.* So, back to today's reality, my questions for clarification are: 1. Is there any existing way or guidance for browser vendors on how to confirm that a plugin can be secured and thus allowed to be instantiated within a sandboxed iframe? 2. Is there any existing way or guidance for library/plugin developers on how to provide appropriate metadata to the browser in order to allow a plugin to be considered secured and thus allowed to be instantiated within a sandboxed iframe? 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? I tend to think not as I did manage to find some revision history that shows that the spec used to say that plugins were outright prevented/disabled rather than secured within iframe sandboxes. However, I also have not found any related discussion/guidance/etc. about how to move forward with secured plugins. *References* [1]: http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/#granular-control-over-capabilities [2]: https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-plugins-browsing-context-flag [3]: https://html.spec.whatwg.org/multipage/embedded-content.html#sandboxPluginEmbed [4]: https://html.spec.whatwg.org/multipage/embedded-content.html#sandboxPluginObject [5]: https://html.spec.whatwg.org/multipage/infrastructure.html#concept-plugin-secure Sincerely, James Greene
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
OK, those answers are all about what I expected, particularly the note about securing the API surface of Flash. So, it sounds like sandboxed iframes will probably *never* support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page *and* top-level page. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site, though it does seem to present a gap as, if I *did* want to sandbox an iframe of my own site, it would probably be to do something more like preventing top-level navigation and/or popups rather than to prevent the instantiation of personally-built plugins... but I cannot achieve the former without implicitly suffering the latter. Not critical but slightly frustrating until the HTML Clipboard API (for which ZeroClipboard is the best interim solution) eventually gets polished and implemented more widely. Sincerely, James Greene On Tue, Dec 2, 2014 at 9:49 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/2/14, 7:46 AM, James M. Greene wrote: 1. Is there any existing way or guidance for browser vendors on how to confirm that a plugin can be secured and thus allowed to be instantiated within a sandboxed iframe? As far as I know, there is not. For Gecko there definitely is not. 2. Is there any existing way or guidance for library/plugin developers on how to provide appropriate metadata to the browser in order to allow a plugin to be considered secured and thus allowed to be instantiated within a sandboxed iframe? Again, as far as I know there is not. 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? The text is intended to allow people to develop such systems if they want to. I don't think any current UAs particularly want to. Note that making sure something with the API surface of Flash is secured would be quite an undertaking... -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
Actually, sandboxing iframes of your own site is one of the main sandbox use cases: ... Oh, hehe. ... it allows limited user upload of content without creating security holes, in theory. Then let us hope that such content creation/collection/uploading doesn't require the use of Flash/Java/etc., eh? :) Sincerely, James Greene On Tue, Dec 2, 2014 at 11:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/2/14, 8:01 AM, James M. Greene wrote: So, it sounds like sandboxed iframes will probably /never/ support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page /and/ top-level page. For Gecko it depends. For example, we plan to ship a PDF viewer plugin (based on pdf.js) that we may decide to allow in sandboxed iframes. Will need to audit it a bit. For third-party plug-ins, I suspect the never answer is a good assumption for now. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site Actually, sandboxing iframes of your own site is one of the main sandbox use cases: it allows limited user upload of content without creating security holes, in theory. -Boris
