[the8472]

> It's probably possible to sanitize all external inputs used in the browser extension such that privilege escalation isn't possible, but the Angular team has tried hard with their sandbox solution with no success. Extension developers will hardly do much better, so it makes sense for Mozilla to ban the whole library.

Sandboxing in JS should be possible these days. Spin up an iframe, add the sandboxing attribute, load javascript into it, postMessage the code you want to execute to it, await the return value. voila, you executed untrusted code in an isolated origin context.

[AgentME]

You can't run code that depends on variables in the page context though. If all the input values are serializable, then you can postMessage them into the iframe too, but you can't serialize objects with arbitrary methods, etc. The code you run in the sandbox can't return back a rich object with arbitrary methods because that has to get serialized back out. You can't use getters and setters to transparently proxy all accesses because postMessage is asynchronous. Even if you restrict everything to only dealing with objects with promise-returning functions, I'm not entirely sure if you can get this all to play nicely with garbage collection (say you have an object outside of the iframe which is only referenced -- through the proxy system -- by an object inside the iframe which is only referenced by that object outside of the iframe)...

Iframe-sandboxing is far from a drop-in solution to this type of problem into an existing codebase.

[the8472]

Access to arbitrary methods would go against the idea of sandboxing anyway. If something references the global object for example you suddenly would have access to a privileged fetch API or other extension APIs.

[tlrobinson]

I believe you could solve the garbage collection problem with WeakMap.

[AgentME]

Maybe if you use a WeakMap with a transferrable object and assuming that if you postMessage a transferrable object and then get it back later and still have the WeakMap recognize it as a key. I'm not very sure that last part would work. I don't think GC-links reach through iframes in a way that would enable that.

WeakMaps are more limited than most people seem to expect. They're powerful tools that enable many new powerful patterns, but they don't expose the workings of the garbage collector. They're very different from Java's WeakHashMap for example. In Javascript, the only way you can tell whether the browser is using a garbage collector or not is to try to run out of memory. Without crashing, there's no way for some Javascript code to observe the runtime's GC behavior at all by design.

[sfink]

Object identity is not preserved with Transferring or regular structured cloning. Transferring is really about the resource represented it held onto by the object being transferred.

If object identity (for the purpose of WeakMap) was preserved, your idea would provide a way to observe GC behavior. Which wouldn't automatically be a complete disaster, though I am personally dead set against it except maybe in some sort of privileged context. Weak references keep getting proposed, and there are some pretty compelling use cases, but there is also some very major risk that we could never back out of once weakrefs were available, and they could permanently hold back future GC performance. (You could easily break deployed web applications by improving GC behavior.)

(Source: I implemented Transferring in general and Transferring ArrayBuffers in particular in Spidermonkey, and I work on the GC engine. And it's nice to see a comment on HN like the parent that gets it right for once!)