3 ms·

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 o

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.
- mrottenkolber 12y ago
  > 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.
  - giovannibajo1 12y ago
    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.pdf 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.
0x0 12y ago
What kind of crazy bug did the CapDaemon have that a single iOS device was able to crash without even trying?!
- mrottenkolber 12y ago
  I don't remember... it was perl?

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.
mrottenkolber 12y ago
> 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.
- giovannibajo1 12y ago
  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.pdf 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.

0x0 12y ago

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

mrottenkolber 12y ago
I don't remember... it was perl?