3 ms·
"It’s kind of baffling that after decades of wifi and captive portals, we still don’t have any kind of standard for the network to properly signal the fact “you
by DannyBee 3y ago
"It’s kind of baffling that after decades of wifi and captive portals, we still don’t have any kind of standard for the network to properly signal the fact “you’ll need to visit <url> in a browser” to a device.
"
We do, actually, and have for decades.
https://en.wikipedia.org/wiki/WISPr https://en.wikipedia.org/wiki/WISPr
Back in ~2010 I wrote a simply python script that parses out the WISPR data that you get, and submits data to the place specified by the XML.
It works on 90+% of hotspots i've ever encountered.
- cbsks 3y agoCould you share your script? That sounds really useful!
- lxgr 3y agoThat sounds cool – are you saying that commercial hotspots actually use this? The specification website seems to be offline, for one thing. Assuming that's indeed a thing, I wonder why the experience (at least on macOS/iOS) is still so mixed then. For example, in inflight Wi-Fi, I practically always have to manually navigate to a non-HTTPS site in my browser to hopefully get redirected to airlinename.com/wifi or whatever they use, to be able to pay for an internet pass (with credit card or by watching their ads). I suspect this is because many airlines now offer free in-flight entertainment and messaging on their free tiers, and the OS's native captive login UI would interfere with that. So I suppose that WISPr protocol doesn't support communicating something like "limited connectivity, navigate to URL x to pay for full access, portal available at URL y".
- DannyBee 3y agoYes, most commercial hotspots use it. Particularly the redirect to login page ones. If you get some form of “you need to login” pop up notification, it is the main way they detect that. Those that don’t give you such a notification are probably not using it