With passwordless public WiFi hotspots, it's easy to demonstrate that packets can be sniffed and (in the case of non-HTTPS traffic) private information gained. While the long-term solution would be to completely implement HTTPS and deprecate HTTP, why is there not a way to encrypt traffic? Traffic traveling through an SSH tunnel is encrypted, so why can the device not negotiate an encrypted transmission with the hotspot so that even HTTP traffic is unreadable? Does such a system/protocol exist, or why has no-one developed one?
There is at least one proposal for this: Opportunistic Wireless Encryption.
In this proposal, the WPA2 password is the same as the SSID, and automatically used by the connecting software.
Fully secure unauthenticated encryption is impossible.
By definition, Public WiFi means neither the Access Point nor the Client has any sort of identification of each other when they connect. Without any identification, there is nothing that the client can do to verify that the encryption key exchanged is one that belongs to the Access Point. If the client and the Access Point owner actually had a chance to exchange identification detail, then for most users, exchanging the WPA2 password is simplest much simpler compared to exchanging certificates or fingerprints, like you'd have to do with SSH/TLS.
With SSH, the client must know the server's certificate fingerprint before connecting, while with TLS the server must own a certificate signed by a CA that is pre-trusted by the client. This certificate contains authentication detail (the public key), that can be used to make spoofing impossible.
The best you can do with systems without identifications like a Public WiFi is TOFU (Trust On First Use). But this is a very weak guarantee when most Open WiFi users doesn't actually connect to the same WiFi more than once and you have tens of Access Point in your remembered network history.