3 ms·
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
by gfodor 7y ago
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?
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 more 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.
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.
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.
- nicoburns 7y ago> I doubt anyone else but them is going to be auditing the various touch points with QuickJS for any kind of sandboxing escaping. I don't think this is relevant. QuickJS-in-wasm doesn't have access to the host environment in the first place. They're not relying on QuickJS for sandboxing, they're relying on WASM. And the WASM runtimes have plenty of eyeballs.
- gfodor 7y agoThere's still interop code though, isn't part of the challenge with this ensuring that there's no security holes in the communication layer between the VM and the outer application? Perhaps they have that concern regardless, but I think a standard set of patterns + shims will eventually converge for Realms.
- azakai 7y agoThere is interop code between the wasm and its JS runtime, but that's very easy to audit for exactly what the wasm is given and what it returns. Also that interop code will be a combination of standard runtime code - very heavily tested, unless they are using something very new - and code they write themselves for their specific application - which they control. So I think this is the safer route for security. It does have a speed penalty atm, but sounds like it's worth it for Figma.