Apple Breaks The Internet Temporarily
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on September 19, 2012 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
Like many people, I upgraded my iPhone to iOS 6 this afternoon. The update for me wasn’t all that exciting, being that I’m on the Death Star network, but it was still worthwhile to upgrade for the Do Not Disturb features.
Shortly after updating, it seems that the wifi connectivity stopped working for me, as well as for lots of other people all over the world. Many people got a screen, similar to what they see when they log in on a wireless network that requires payment or agreement to certain terms and conditions. It appears that whatever URL the iPhone utilizes to determine whether or not connection to the outside world is established was returning a 404 error – not what the iPhone expected, and thus resulting in the display of the Log In screen.
This highlights a number of programmatic and user experience errors that I think are worth discussing, as a warning to other programmers.
1. Single point of failure.
It appears that Apple has a single point of failure, which is a URL (http://www.apple.com/library/test/success.html) used to determine whether or not the connection to the network allows a connection to the outside world. But a failure of that URL or server, resulting in an unexpected response, caused a large number of people to experience an “outage” of wifi connectivity. The issue was so widespread that it began trending on Twitter. This single point of failure resulted in hundreds of thousands of people reporting their problem.
2. Poor error handling.
Most of the time, when a user is redirected to pay for wifi or accept an agreement, they receive a 301 (temporary redirect) or a 402 (payment required) status code. At least, they should. Reaching a webpage normally results in a 200 status code (200 OK). Apple’s programmers probably never assumed that the endpoint would go down; therefore they probably only check for two conditions: 200 OK and everything else. The result? Receiving a 404, an error code, should have resulted in the execution of some kind of logic. But because the iPhone didn’t see it as a 200 OK status code, it prompted the user to log in.
3. Misuse of user trust.
A number of people I was discussing the problem with became convinced that Apple was somehow “in the middle” of their internet connection. While it appears that this is not true, the fact that an Apple 404 page came up during the wifi authentication process was disturbing to many of them. The vast majority of users are not technical; they are not able to determine whether or not Apple is merely testing for active connections to the outside world or whether Apple is, in fact, monitoring them.
The Bottom Line
Small things can turn into big deals. While Apple fixed the issue quickly and it is no longer redirecting people to an Apple 404 page, there’s a large contingency of users who will be looking for an explanation or have less confidence in their phones. The single point of failure offered by Apple to determine wireless network connectivity offers hackers or others an opportunity to mess with a very large community of users very quickly. And the lack of transparency from Apple about these kinds of issues (I’m certain they won’t issue a statement) only breeds a lack of confidence.
Write better object oriented PHP today.
Object oriented programming always leaves you with a headache. What if you could master it instead?Get the book now! »