11 ms·

iOS have had good user experience for captive portals since a long time (iOS 3 I think), and also Mac OSX. They automatically detect when a captive portal is pr

iOS have had good user experience for captive portals since a long time (iOS 3 I think), and also Mac OSX. They automatically detect when a captive portal is present by doing a background connection to some Apple-owned property and trying to download a small text file; if it fails for any reason, they bring up a modal panel showing the captive portal and letting the user login; then, they detect when the Internet access is active and close the panel (or, lately, let the user close the panel with a "Finish" button). What's more important is that the whole operating system / applications are not given the signal "network is on" until the whole process is finished, so you don't get one dozen of failures from applications that try to refresh in background and can't access their backend servers. This said, I really hate the fact that the WiFi alliance has left us in this very sad state. Like many similar committees, they move too slowly; captive portals arose from a real-world problem that wasn't solved by the WiFi standard, so people had to come up with weird DNS/HTTP interceptions that fail in so many regards it's not even funny. If there's somebody to blame, it's not operating systems for not adding weird heuristics like Apple did, but Wifi Alliance for not bringing to the market a good solution for handling hotspots soon enough.

khc 12y ago
I've never used iOS so I didn't know about it does this, but I've always wondered why Android didn't do the same thing.
- quentinp 12y ago
  It does since 4.0 at least: http://android.stackexchange.com/questions/45629/what-android-versions-have-captive-wifi-detection http://android.stackexchange.com/questions/45629/what-androi...
  - khc 12y ago
    it has a notification telling the user that they need to sign on, but it also tells other applications that a wifi connection is available, which causes all of them to try to sync.
mrottenkolber 12y ago
Apple customers, where phoning home on every network connection is good UX. What is wrong with you people? I had this behaviour crash a captive portal daemon once, was fun tracking down the owner of the device in question in the building. "CapDaemon crashed, request came from around room A2.011!", "Let's get him before he's gone!", "Hey, Mr., do you own an Iphone or I pad? Yes? Please come with us. We need to have a debug session with you."
- giovannibajo1 12y ago
  It is good UX. For privacy concerns, it's already phoning home on every network connection for push notification registration (at the very least), so your objection is moot to me. To handle this less centrally, you would need a distributed list of URLs to be used for captive portal checks, with servers handled by different entities, and each device selecting one at random from the list. This wouldn't change the UX though. For your other remark, if the captive portal crashes for a standard HTTP GET to a normal URL, you can't really blame this on anybody else but the captive portal developers.
  - nandhp 12y ago
    Here are the major implementations: http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html http://clients3.google.com/generate_204 http://clients3.google.com/generate_204 http://www.msftncsi.com/ncsi.txt http://www.msftncsi.com/ncsi.txt And some other implementations of dubious longevity: http://start.ubuntu.com/connectivity-check http://start.ubuntu.com/connectivity-check http://network-test.debian.org/ http://network-test.debian.org/ Now, if only NetworkManager could add support for this.
  - sbierwagen 12y ago
    To handle this less centrally, you would need a distributed list of URLs to be used for captive portal checks, with servers handled by different entities, and each device selecting one at random from the list. I dimly remember that the way Android does it is by requesting a list of randomly generated garbage domains (like http://aghepodlln/ http://aghepodlln/) and seeing if they get a response. If they do: captive portal.
TazeTSchnitzel 12y ago
OS X's solution is really nice, I only wish other platforms would do it. Microsoft do a similar connectivity check on Windows, yet they don't deal with the portals.
- Nullabillity 12y ago
  I believe both Windows and Android give you notifications that there is a captive portal active, but it will just open it in your default web browser instead of a dedicated one.
  - TazeTSchnitzel 12y ago
    I wish they'd do the dedicated thing. I hate opening my browser to see all my tabs either warning triangles, or portal pages. I want to get that over with before opening my browser.
    - cpach 12y ago
      Could it be that Microsoft won’t ”force” the user to use Internet Explorer because of anti-trust concerns?
      - TazeTSchnitzel 12y ago
        Doubt that. You wouldn't be forced to use it here anyway.
ferongr 12y ago
>if it fails for any reason, they bring up a modal panel showing the captive portal AFAIK, technically, there's no standard address for a captive portal's location so iOS probably tries to navigate to a website. The router then poisons the DNS response and the captive portal loads. Android devices do the same thing to my knowledge. My Samsung pops up a notification that when tapped opens the browser and tries to navigate to Google. If a login happens before the user opens the notification (for example, by an app running a background service like the Fonera app) the notification is cleared automatically.
- 0x0 12y ago
  Actually, most captive portals don't poison the cache (because that would break the web site you tried to load), but answers on port 80 for any and all IP addresses.
  - ferongr 12y ago
    To my knowledge you can use a TTL of 0 and then you have no problems.
    - 0x0 12y ago
      Wouldn't that cause problems with (a) browsers that cache dns for a little while anyways, and (b) clients arriving on the captive net but already holding a long-lived cached proper dns result?

khc 12y ago

I've never used iOS so I didn't know about it does this, but I've always wondered why Android didn't do the same thing.

quentinp 12y ago
It does since 4.0 at least: http://android.stackexchange.com/questions/45629/what-android-versions-have-captive-wifi-detection http://android.stackexchange.com/questions/45629/what-androi...
- khc 12y ago
  it has a notification telling the user that they need to sign on, but it also tells other applications that a wifi connection is available, which causes all of them to try to sync.

mrottenkolber 12y ago

Apple customers, where phoning home on every network connection is good UX. What is wrong with you people? I had this behaviour crash a captive portal daemon once, was fun tracking down the owner of the device in question in the building. "CapDaemon crashed, request came from around room A2.011!", "Let's get him before he's gone!", "Hey, Mr., do you own an Iphone or I pad? Yes? Please come with us. We need to have a debug session with you."

giovannibajo1 12y ago
It is good UX. For privacy concerns, it's already phoning home on every network connection for push notification registration (at the very least), so your objection is moot to me. To handle this less centrally, you would need a distributed list of URLs to be used for captive portal checks, with servers handled by different entities, and each device selecting one at random from the list. This wouldn't change the UX though. For your other remark, if the captive portal crashes for a standard HTTP GET to a normal URL, you can't really blame this on anybody else but the captive portal developers.
- nandhp 12y ago
  Here are the major implementations: http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html http://clients3.google.com/generate_204 http://clients3.google.com/generate_204 http://www.msftncsi.com/ncsi.txt http://www.msftncsi.com/ncsi.txt And some other implementations of dubious longevity: http://start.ubuntu.com/connectivity-check http://start.ubuntu.com/connectivity-check http://network-test.debian.org/ http://network-test.debian.org/ Now, if only NetworkManager could add support for this.
- sbierwagen 12y ago
  To handle this less centrally, you would need a distributed list of URLs to be used for captive portal checks, with servers handled by different entities, and each device selecting one at random from the list. I dimly remember that the way Android does it is by requesting a list of randomly generated garbage domains (like http://aghepodlln/ http://aghepodlln/) and seeing if they get a response. If they do: captive portal.

TazeTSchnitzel 12y ago

OS X's solution is really nice, I only wish other platforms would do it. Microsoft do a similar connectivity check on Windows, yet they don't deal with the portals.

Nullabillity 12y ago
I believe both Windows and Android give you notifications that there is a captive portal active, but it will just open it in your default web browser instead of a dedicated one.
- TazeTSchnitzel 12y ago
  I wish they'd do the dedicated thing. I hate opening my browser to see all my tabs either warning triangles, or portal pages. I want to get that over with before opening my browser.
  - cpach 12y ago
    Could it be that Microsoft won’t ”force” the user to use Internet Explorer because of anti-trust concerns?
    - TazeTSchnitzel 12y ago
      Doubt that. You wouldn't be forced to use it here anyway.

ferongr 12y ago

>if it fails for any reason, they bring up a modal panel showing the captive portal AFAIK, technically, there's no standard address for a captive portal's location so iOS probably tries to navigate to a website. The router then poisons the DNS response and the captive portal loads. Android devices do the same thing to my knowledge. My Samsung pops up a notification that when tapped opens the browser and tries to navigate to Google. If a login happens before the user opens the notification (for example, by an app running a background service like the Fonera app) the notification is cleared automatically.

0x0 12y ago
Actually, most captive portals don't poison the cache (because that would break the web site you tried to load), but answers on port 80 for any and all IP addresses.
- ferongr 12y ago
  To my knowledge you can use a TTL of 0 and then you have no problems.
  - 0x0 12y ago
    Wouldn't that cause problems with (a) browsers that cache dns for a little while anyways, and (b) clients arriving on the captive net but already holding a long-lived cached proper dns result?