Wow, I had no idea this was this much of a thing.

A few months ago I thought of the following crazy idea, which I dismissed after realizing it probably wouldn't scale too well. Maybe I'm wrong and it's worth pursuing (obviously for free).

Here's how it would work. Is this a good idea?

- A connection request broker functions as a central hub

- Nice users configure their ISP access credentials in a small Win32/Linux/macOS daemon that connects to the hub and idles waiting for connection requests

- At some point a wild device wants to connect to an ISP-provided Wi-Fi hotspot, and starts a companion app

- The app a) initiates a Wi-Fi connection to the network in question, which should result in a captive Wi-Fi situation requiring a login, b) opens a TCP connection to the captive login server, and c) sends a connection request to the broker over a pre-existing cellular link, providing a reference/handle to the opened TCP connection.

- The broker selects a random daemon then sends a connection request event to the selected daemon. The resulting handshake provides the daemon with a handle to the TCP socket the app opened.

- The broker now functions as an intermediary, passing raw TCP packets back and forth between the daemon's socket handle and the TCP connection opened by the app.

- The daemon is now able to reach through the just-in-time proxy connection that has been established to perform whatever ISP-specific magic is needed to get past the Wi-Fi captive login page.

- ___IF___ your ISP uses HTTPS for its Wi-Fi login, the daemon will thusly be able to send your ISP login credentials directly through an encrypted tunnel (the HTTPS link) without even a malicious app user ever being able to access your password.

IMHO the connection broker should definitely marshal requests between apps and daemons, so malicious app users can't get daemon IP addresses (which would only work out badly).

In any case, for something like this to work out scalably, people would need reassurance that the risks are low and the benefits are high.

And the main problem, at the end of the day, is that you're all but running a Tor node if you do this. :/

You probably wouldn't add this to the Raspberry Pi you've already got running at Grandma's house for whatever reason, because it's simply too open-ended.

But before even that, there's the problem of network effects: this would only work if thousands of users provided ISP access credentials, either via the daemon approach or by simply providing their ISP access credentials to the central hub directly (!).

Maybe there are people out there that would be willing to do this though...?

Technically this is sadly (lol) one of my better ideas, but practically it's.... just a tiny bit... ._.

---

For completeness, Telstra in Australia also provide a pretty much identical feature called Telstra Air. You select the special modem option, it creates a Telstra Air hotspot, your account gets the "can access Telstra Air on others' hotspots" flag enabled. Telstra Air access points also hide inside specially marked payphones (https://www.google.com/search?q=telstra+air+payphone&tbm=isc... - the top is pink and/or has a Wi-Fi symbol on top).

On the OP page, there's a similar question:

> Is there a limit to the number of devices that can connect to Cox Hotspots at one time?

> Cox Hotspots is limited to five devices simultaneously connected so that users can enjoy a better experience.

FWIW, as per https://crowdsupport.telstra.com.au/t5/broadband-nbn/telstra...,

> only a maximum of 3 devices can connect to the Telstra Air Network in Australia at any given time.

(That is so poorly worded :D - sounds like it's applying to the entire nationwide network lol)