Hi, one of the project's co-authors here (SAPI that is). The aim of SAPI is a bit different than whole-process sandboxing. It's about retaining the original ru

Hi, one of the project's co-authors here (SAPI that is). The aim of SAPI is a bit different than whole-process sandboxing. It's about retaining the original running speed (and lack of sandboxing constraints) of the main project part, while making sure that only some parts are isolated (sandboxed), and the programming interfaces to the sandboxed parts still look familiar. I'm not that well-versed into how WASM works when it tries to integrate with the rest of OS. But I'd assume it's some form of whole-process sandboxing, where practically all code is WASMized, and only some kind of loaders and trusted stubs are written in native assemblers (something has to invoke syscalls in the end). In this case one can use Sandbox2, which is part of SAPI, though not very prominently exposed - https://github.com/google/sandboxed-api/tree/main/sandboxed_api/sandbox2 https://github.com/google/sandboxed-api/tree/main/sandboxed_.... It's a full-featured Linux sandbox in its own rights, with C++ API. Examples might be englightning: https://github.com/google/sandboxed-api/tree/main/sandboxed_api/sandbox2/examples https://github.com/google/sandboxed-api/tree/main/sandboxed_...