The biggest flaw I've heard with WebAuthn/other attempts to do security critical or zero-trust tasks in client-side JS: even if you're *theoretically* not trusting the server with your secrets, you're *still* trusting them not to be so thoroughly compromised/malicious that they send malicious JS (which of course gets re-downloaded on each visit). See e.g., https://github.com//bitwarden/web/issues/660#issue-705107304
But couldn't a site mitigate that by publishing a hash of the document HTML – basically like SSH's known_hosts?
1/n
@codesections If I can get the site to distribute malicious JS, why couldn’t I also get it to distribute the correct hash for my JS? #JustSaying It would seem the integrity protection information will need to come from an out-of-band context, i.e. from a system that is not the web server I’m checking, and that is in another trust zone?
> If I can get the site to distribute malicious JS, why couldn’t I also get it to distribute the correct hash for my JS? #JustSaying
Yeah, I mentioned that "the server hosting the hash" could be compromised too – but it's worth emphasizing that it needs to be a *different* server than the primary one, or the whole exercise is pointless.
Assuming a separate server, though, it should be easy to secure if it only needs to serve static text.
@codesections IPFS seems to work this way going by their docs: URI's are hashes, but there are also stable hashes that are updatable pointers to content hashes. They don't document any problem with the approach. Also, IPFS seems to subsume CDN's and it still claims to work @c_alpha
