Sure, but then you’ve just shifted the problem up a level. Now I have to trust that the user id you provide me in the insecure channel really is you. Which means either trusting the insecure channel or trusting that the web app has confirmed who you are in some other way before giving you an ID.

We have to reject the first since we could skip all the asymmetric crypt and just send a symmetric key directly in the insecure channel.

If we’re trusting the web app has confirmed your identity, we’ve moved from “just quickly go to this page and it’ll generate you a public key” to “go to this site, upload a photo of your ID and a video of you saying that its you and whatever other verification is needed, then it’ll give you a public key”.

You originally wrote:

The one sticking point is that your recipient needs to visit the site before you can send your vacation photos to them, but is it really that hard?

The hard part isn’t them going to the site in advance, it’s them establishing trust with the site that they are who they claim to be.

Even if you’re using asymmetric cryptography, you still have to trust the insecure channel. If an attacker can replace the URL sent there with their own then they can have the sender encrypt the files with an attacker controlled public key rather than the legitimate one

It’s not that you change the passwords for each website often, it’s that you use a different password for each site. That way if one site gets hacked and your password is leaked, it can’t be used to access your accounts on other sites.

If you have a nut allergy you probably have never tasted nuts and wouldn’t know that was what you were tasting