Hacker News Reader

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.

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.

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.

Could it be that Microsoft won’t ”force” the user to use Internet Explorer because of anti-trust concerns?

Doubt that. You wouldn't be forced to use it here anyway.

>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.

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.

To my knowledge you can use a TTL of 0 and then you have no problems.

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?

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.

It does since 4.0 at least: http://android.stackexchange.com/questions/45629/what-androi...

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.

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."

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.

Here are the major implementations:

http://www.apple.com/library/test/success.html http://clients3.google.com/generate_204 http://www.msftncsi.com/ncsi.txt

And some other implementations of dubious longevity: http://start.ubuntu.com/connectivity-check http://network-test.debian.org/

Now, if only NetworkManager could add support for this.

  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/) and seeing if they get a response. If they do: captive portal.

> so your objection is moot to me

"...because Apple already fucked it up elsewhere so double fuckup doesn't give extra points."

> you can't really blame this on anybody else but the captive portal developers.

I don't think I did, thats just how I found out about this particular appleism. Also: This behaviour enabled us to track down that device and its owner physically too. So think about the sensibility of this "feature" in this light. Every other device would have enjoyed relative anonymity amongst the other devices in the building.

We're speaking of a device where Apple can silently push kernel-level code over-the-air at any moment. Surely an extra IP connection to an Apple server is not changing anything in the picture, but it is helping millions of people using their device without getting weird error messages or certificate errors every time they connect to a hotspot.

If you don't trust Apple with your IP, you shouldn't use a device which runs their kernels, that's a no brainer; if you do trust them, though, you might appreciate the way they go through multiple hoops not to handle too much of your sensitive personal data, see for instance the design of iCloud Keychain: http://www.apple.com/ipad/business/docs/iOS_Security_Feb14.p...

So it's not like the impact of an IP connection is not taken into account in design considerations; it's just that it doesn't look so important in the big picture of the security and privacy implications of using such a device. For personal passwords, different avenues are taken.

What kind of crazy bug did the CapDaemon have that a single iOS device was able to crash without even trying?!

I don't remember... it was perl?