I am currently writing captive portal support for a big-name internet provider. This article only scratches the surface of how difficult it all is. Each OS is different, and each is painfully undocumented
i am sorry, this is absurd line or reasoning. This logic has never worked in the history of business. It can only work in lisenced proffeshions like law and accounting where doing something nasty would loose you your lisence and your boss knows that, so literslly noone would agree to do it
secondly, captive portal at prague airport actually has a function - it provides you with up to date information about flights and dates.
You can provide flight information without a captive portal, just stick it on a normal web server. Maybe stick QR codes around the airport to help guide people to it. Bonus: you can access it outside of the airport.
they can and always do find someone else to do it. This line of reasoning literally has never worked
In order for this scheme to work, unions are needed. A professional union which like doctors associations would enforce ethical standards on its members and use collective bargaining to freeze malefactors out of the industry.
It wouldn’t be as good as how doctors have it, with legal weight and governmental recognition, but it would be enough.
Have you never considered this scenario?
In general, someone needs to take a quick look it the development time and customer support involved really can be motivated from the extra earnings. The trend is that fewer and fewer bother, and just see complimentary wifi as a value add instead.
Airports, cruise ships, and other places where it does make economic sense are better served by real things like 802.11x and per-user QR codes.
I do think the internet should be free, but how we sustain that is a pretty viable question. APs need to be installed, configured, and monitored. When spaces grow, APs usually need to be reconfigured or moved.
I know that airlines are fairly low margin businesses, based on what I've read from the recent bankruptcy stuff. I am curious about who owns airports and what their margins look like.
Respect redirects over HTTP or gtfo.
On mobile OSes, the captive portal is opened in a sandboxed embedded browser. OS designers want to prevent the captive portal from being used maliciously, so they understandably block off a lot of functionality. Problem is they don’t tell you what features they turn off. I.e As far as I can tell iOS blocks off external links and ajax requests (!)
On iOS you can’t close the captive portal programmatically. The user must submit an html form (or similar) and navigate to a new page. Only then will the OS check /mobile-hotspot-detect and realize that the user is connected to the internet and present the user a button to close the captive portal. This is very clunky and makes it impossible to make a sleek user experience
Android automatically closes the captive portal when it detects a connection. This often confuses the user (why did my page suddenly disappear?) and makes it impossible to make a consistent mobile captive portal experience between iOS and android
Androids kernel seems to have two separate, independent captive portal checks
iOS only checks the content of the connectivity check endpoint, while android also checks for any form of a DNS redirect in its requests
Microsoft checks against two different domains for a captive portal
Many Non-stock android distros check against their own custom (and undocumented) endpoints
There was a dhcp option recently introduced to help clean up this mess. Problem is, nobody supports it. Not even Apple (who seemed to have played a hand in the RFC) supports it
Linux is a lost cause
Figuring this all out took over a month of trial and error. Even then many of my conclusions are probably wrong. None of this is documented or standardized!
The DHCP standard was such a waste of time. Ignore it completely, no client support whatsoever.
Intercepting all plain HTTP traffic (just drop https) and responding with a 30x redirect to your captive portal web page seems to be the ad-hoc "standard". Your captive portal domain can be served under secured HTTPS just fine.
I fully agree with the sandboxed browsers pain and absolute impossibility to get a nice consistent UX across platforms.
I mean, captive portals started out as a hack, then captive portal detection was a hack against that hack... It's effectively an antagonistic relationship.