You do have to trust Fabrice Bellard not to ship a compromised client to the browser, but a.) that's much less trust than you'd be giving to Shellvault, and b.) there's no reason you couldn't self-host the files for jslinux.
JSLinux is not magic - it too does not have raw access to TCP sockets required to terminate SSH in the browser as you think it does.
As described in its FAQ, it uses websocketproxy[1] for network access. This is a separate server application running on https://relay.widgetry.org/ . JSLinux absolutely cannot access raw TCP sockets, and ergo cannot terminate SSH connections, without it connecting to this websocket proxy. You can see this even in the Network tab of devtools.
Sure, you could spin up a websocketproxy yourself, but as I explained in a previous response to you, the value proposition of Shellvault is that you don't need to spin up any servers and host them yourself - this service does it for you.
As I explained above, the websocketproxy has no more privileged access to your networking than any of the other routers on the internet, whereas Shellvault has plaintext mitm of your entire session. Can you see the difference?
> JSLinux absolutely cannot access raw TCP sockets,
Agreed.
> and ergo cannot terminate SSH connections
No. The SSH application layer is terminated in the browser.
Just tried it out. Used ngrok to tunnel port 22 of my laptop and ssh'd into it from jslinux (my laptop has no public DNS entry and my home network is not on IPv6 yet).
I'm suggesting that Shellvault could operate an untrusted intermediary by terminating SSH in the browser instead of on their server.
If you don't believe it's possible, load this: https://bellard.org/jslinux/vm.html?url=https://bellard.org/... and use the SSH client. It works already.
You do have to trust Fabrice Bellard not to ship a compromised client to the browser, but a.) that's much less trust than you'd be giving to Shellvault, and b.) there's no reason you couldn't self-host the files for jslinux.