They have a paper about their architecture.

Basically, your master password is never sent, and everything is encrypted and decrypted locally.

You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.

Yes we can degenerate into inordinate amounts of rabbit holes. For 1, you can audit the JS that runs on your browser, it's not hiding (so it's not strictly fair to say that just because you loaded a webpage in your browser from their server it can't be trusted). And anyway, generally, your argument holds for any software interaction ever. GH doesn't have to ship you the repo that you browsed on the web client. A malicious actor could have compromised their infra and be serving fake code in the web UI but have added all sorts of malware to the stuff you download. Apple app store doesn't eve ship you the exact binary the developer uploaded. Scary. At some point you have to decide which threat vectors you actually care about. Give me a scenario and I can tell you how someone can theoretically attack it and why you're not safe. The only thing you can be 100% sure about is manually auditing every single release at the source level and building it yourself.

But your data is encrypted client side. It shouldn't be too difficult to audit thay the client side code matches a build of their original sources.

Then host your own.

They have a paper about their architecture.

Basically, your master password is never sent, and everything is encrypted and decrypted locally.

You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.

The proxy would only see encrypted blobs; the client (which afaiui can be compiled and run locally despite using their hosted service) never sees the passwords in clear.

As long as the client and cryptography are uncompromised, the server only gets metadata.