Why is the Web Worker inside an iframe?

[laughinghan]

Is there any documentation anywhere as to why the Web Worker is launched from inside an iframe, as opposed to just relying on the worker for isolation?

I understand defense-in-depth, but of course there's more to it than just "more layers", or else you'd have 3 or 10 nested iframes. Is there a specific reason to think someone could break out of a worker but run into trouble breaking out of the iframe? If anything frames seem easier to break out of than workers, what with its partial access to parent windows and heavily polluted, ever-growing global namespace.

[asvd]

#1

although even iframes seem to be not secure enough

#33

so please conside jailed as broken atm

[willstott101]

Have you got a source or known exploit which makes this library unsafe for browser usage? Or is it only broken in node.js?

[Venryx]

@asvd Any update on @willstott101's question above?

I'm only aware of exploits described for the node.js version (#33), not the browser version. (would be good to have a confirmation from the repo owner on the browser-version's status)

EDIT: My guess is that @asvd was referring to this web issue: #43

However, if my analysis is correct, that's just due to the non-standard access-control-allow-origin header for the demo site, not an actual vulnerability in the approach jailed uses.

[spielzeugland]

One reson to do so, ist the fact that you cannot Set CSP Headers for Web Workers. They inherit the settings from the hosting page.
In Addition the iFrame must have an different origin (or a strict Sandbox config, which ist mit that easy).
These are General Statements without having looked at the concrete Implementation of jailed.