Not really, modern browsers warn about self-signed certificates the same as HTTP (or sometimes even more). And obviously you can in theory verify the signature's fingerprint akin to a trust-on-first-use model like SSH.
May not be as standard as a CA model in the current landscape, but trust on first use has shown to be perfectly fine for SSH, and has the advantage that you're not trusting third parties to only sign valid certificates for authorized parties.
I think you lost the context
> modern browsers warn about self-signed certificates the same as HTTP
So if I can read and understand those browser warning and am not a complete idiot, I will close the browser tab instead of proceed despite the warning. Which is the correct choice.
So now I cannot read the website at all.
Otherwise, if I do make the bad decision and accept the certificate, I don't know what will happen. But with HTTP, at least the browser says clearly that the site is unsafe.
So the fact that the website does have a certificate and serves HTTPS, as suggested in the GP, is completely irrelevant and useless.
> trust on first use has shown to be perfectly fine for SSH
If that is MY server or a server I trust/can verify. I don't know about you, but I never SSH into someone else's server and just blindly accept the keys. GitHub, for example, provides their SSH keys: https://docs.github.com/en/authentication/keeping-your-accou...