How do you guarantee the server that sent the Javascript to the browser, which stores the client secret key in the browser, didn't get hacked to also send the client secret key somewhere else after it was generated in the client?
Yeah, this is definitely a risk of any in-browser demo of this tech. The story for apps is much better, since there's a routine installation process, signatures are checked, etc. We'd like private retrievals to eventually be part of the browser itself, so that it can make a kind of "private GET" request natively.
We'd also love to bind our client JS code to a hash of our build output from GitHub, but as of now there's no simple way to do this that the browser will pin automatically - integrity checks are good, but don't prevent the server from just changing the hash. We've toyed with writing an extension for this, but haven't gotten around to it.
I've wanted this too! You could include subresource integrity hash in the URL that the browser will check against the page. This would make things like Cryptpad and Skiff, or group invite links in Signal, way more secure.
This seems like it would be a cool browser standard. The browser could check that the specified SRI hash matches one published by some other entity, and then include extra information in the ‘lock’ icon or dialog, that goes further than TLS.
Usually, when I have an idea for a standard, it turns out one exists, so maybe I’ll do some digging…
Assuming the malicious server operator, you need to obtain the client out-of-band (package manager, app store etc), or if we require it’s the web app - thru somethink like an IPFS gateway where you can be sure the bits received match a particular hash.
Or do a git clone (pinned to commit hash) and host the client locally, I guess))
