In case of in-flight Wi-Fi, the credentials/QR code can be printed on the boarding pass, or available in the app (the app caches it in advance while it's still on the ground, so when in the air you can use those credentials to connect).
This doesn't cover 100% of use-cases but it would at least cover a big one (a significant amount of public Wi-Fi is "value add" to another service - whether restaurants, hotels, flights, etc where there's an existing channel to provide one-off wi-Fi credentials over), it's a shame nobody deploys this.
One concern might be expiring access credentials (not sure if most OSes will re-prompt for a new password or just give up), but you could just make the EAP credentials per-user instead and redirect users to the captive portal again once needed.
This leaves clients not supporting WPA-EAP, but these could just continue using the regular unencrypted/MAC-authenticated service.
Only works with IFE equipped planes, of course.
Though you could route around these problems, but giving them both a scannable code, and underneath some credentials as plain text they could type.
That way you'd at least have the protection of the WPA GTK.
It's not airtight, but better than the system it would be replacing.
PS: I'm a couch expert so I have no idea if there's a problem with this idea.
The user can go in and forget the open network of course, but most won't know to do that.
This hack just goes a step further to plot the data over time.
The state of "open Wi-Fi" security is actually really sad. I'm not aware of an easy way for the airline to actually do better than this!
I suppose they could use Opportunistic Wireless Encryption [1] and bind session authentication to that (i.e. authenticate a given OWE session, not a given MAC address) if the device supports it, as at least modern Apple devices do? But I have no idea how stable an OWE session is; it would be very inconvenient to have to login again every time my device switches between access points.
In any case, I'm sad that this isn't a solved problem yet, and paid Wi-Fi (as well as securing free Wi-Fi) still requires custom and clunky solutions like unreliable captive portals that need to pass through selective traffic (e.g. for 3DS, for payments, sometimes emails for password reset codes etc and more).
A standardized endpoint and API would also be nice, i.e. something to tell the client whether it's connected, restricted (i.e. able to only access a limited set of hosts such as the in-flight map as described in the article), or needs to pay/authenticate (and if so, at which URL). This could then yield an authentication token, to be provided for seamless reconnections for the same session.
There's "Hotspot 2.0" and WPA-EAP (i.e. WPA Enterprise), but these don't really have a good story for "pay via web portal" style usages and are more geared towards wireless carrier operated hotspot networks and corporate scenarios, respectively.
[1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...