The problem I've run into with public key pinning is captive portals. Mobile operating systems or browsers need to provide a better user experience for captive portals.
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.
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.
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."
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.
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.
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.
"...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.
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.
If a captive portal is able to display a valid web page when you try to visit an HTTPS website, that would be a serious red flag.
Just because your solution is problematic doesn't however mean that your point is not correct. The problem here is indeed with captive portals.