I'm pleasantly surprised to read a fairly detailed, apparently honest analysis of their security decisions and trade-offs from a company selling proprietary software services. I don't have an opinion of whether technology X they used in the past is better Y, but this kind of <i>detailed</i> disclosure is rare and they should be thanked.<p>In the non-software world, how often do we get any kind of explanation? What was the mechanical problem that delayed my flight for 14 hours? I've never gotten even a two-sentence explanation; sometimes they lie (the announcement says "it's the weather" when the pilot has already admitted it's mechanical). I can list a hundred examples involving banks, government, and utilities where I've sought an explanation for a weird failure, but gotten absolutely nothing. The software world is leading the way in transparency compared to pretty much every other industry.
Running a javascript interpreter, written in C and cross compiled to WASM, in a browser, does feel like a joke. However, it probably is most simple and effective way of running user submitted code in a sandbox which they can't escape from.
I was really skeptical when they announced the realms approach, and feel the same way about this one. The simple solution (and one that relies on proven browser-provided apis) is to isolate such code within an iframe. Yes there is some overhead when communicating over the postMessage api but it is not great.
I am really thankful the Figma team is talking about this stuff (especially with regard to security). I think providing a plugin API so that other can extend their application is pretty smart and in general brings web applications closer to traditional desktop applications where plugins are way more common.
> Figma seeks to ensure that plugins can only be run by an explicit user action.<p>> Figma seeks to ensure that plugins can’t run by themselves.<p>What about triggering plugins from implicit user actions? [1]<p>[1] <a href="https://www.figma.com/plugin-docs/whats-supported/#trigger-plugin-code-on-events" rel="nofollow">https://www.figma.com/plugin-docs/whats-supported/#trigger-p...</a>
I gotta say, the Figma team's blog has been on fire with quality posts about their sandbox.<p>They've posted all details about their sandbox implementation, then all the details about this dependency vulnerability that they were on top of, they showed how they reviewed logs for exploitation traces to find there was none, and finally described their strategy for future proactive protection.<p>Kudos all around!
It's non-obvious to me why a security incident like this should dictate switching engines over to Plan B. Does the incident reveal any new posterior information about the security of using Realms, that wasn't available at the outset?<p>The reason Realms seems like a smarter move overall is because in relative terms Realms has a wide variety of stakeholders, is (at least so far) on the ECMA track, and generally speaking seems like the 'right' solution to this problem. I can empathize with not wanting to be the product pushing the envelope and finding these holes, but at the same time having someone like Figma validating things seems like it could push the path dependencies towards <i>more</i> organizations investing in Realms for this kind of thing, and hence cause acceleration towards maturity -- the net effect being Figma's plugin platform being more secure, more quickly than if they back off from Realms.<p>The VM-in-WASM approach, while in theory fundamentally less likely to be exploited, seems risky from the perspective that now Figma basically is on their own for finding any places where it does in fact have a hole -- I doubt anyone else but them is going to be auditing the various touch points with QuickJS for any kind of sandboxing escaping. QuickJS is also a very new engine, written by a single individual which is also a factor (who by all accounts seems to be capable of 100 man-hours per hour, but nonetheless.) Insofar as Figma is a juicy target, you can be sure that probing QuickJS for potential issues will now be a worthwhile endeavor to hackers, and it seems likely that unless others start doing this approach that Figma will be the only party who will be incentivized to try to keep ahead of identifying exploits.<p>I acknowledge it's a bit of a catch-22 -- they want to ship safe functionality now, but also don't want to use tech that won't be the safest, most adopted standard and best option in the long run -- but that choice, today, seems like a security risk. I'm curious if there is any other additional context that warranted pulling the escape lever. I understand they can switch back at any time, but it does seem that this event increased their priors on future vulnerabilities in Realms.
> We now use QuickJS, a JavaScript VM written in C and cross-compiled to WebAssembly. This was our backup plan in case the Realms shim approach didn't work out. We were able to activate our backup plan very quickly thanks to a swappable architecture.<p>I had high hopes for Figma for their sensible security choices before this blog post. But reading that they are using QuickJS even when it is unstable and they have cross-compiled to WASM doesn't improve the security prospects. Sandbox escapes are still a thing in JS VM and the WASM VM these days and using it alone still won't solve these issues. Lite-mode V8 might have made more sense to embed.<p>Having a plugin system and avoiding malicious code-execution was always going to be a tricky situation, especially on the web. Some form of isolation must exist between the VM and the code that disallows this better than a sandbox. As for choosing JS engines, I don't think choosing QuickJS was a sensible choice in terms of security.