Hacker News Reader

Comment by sjtrny | Hacker News Reader

Why? To confirm connectivity.

Welcome to HN, where answering a question gets downvoted.

My browser doesn't do that so there's really no need for a TV to do that.

Are you sure your browser doesn't do that? There's usually some code that checks for 'captive portals' - i.e. wifi providers that want you to login before giving you a real internet connection.

What I mean is that my browser (Safari) doesn't dial home (Apple) to decide whether or not it can try serving me content (HackerNews). NB That doesn't mean it never connects to Apple without my knowledge (or elsewhere), but rather that it's not a point of failure.

Edit: I'm making a distinction between what my browser does vs the OS and wifi. In any case, your home TV doesn't really have to deal with captive portals.

Your Mac does exactly that actually.

http://blog.erratasec.com/2010/09/apples-secret-wispr-reques...

Apple broke the page once and everybody's wifi broke in response. Single point of failure.

Thanks for the info. That page talks about iOS but is the same true of OSX?

Something like that, most likely -- OS X also detects when a network captures and redirects requests until you log in/agree to terms/whatever, and pops a special window for you to do that in as soon as it connects to such a network.

How did everybody's wifi broke? I would have imagined that the only thing that would have happened was that, for wifis that required a login portal, you would have to launch your browser manually and let the portal hijack any pagerequest.

How did they manage to ensure that this didn't work if there wasn't such a portal or if you did it manually?

It's not safari that does it but the "OS" itself, and by that I mean the wireless networking tool. I would imagine that there's some code that runs upon successful connection to an AP and checks to see if you're in a captive portal or not.

The resulting UI looks like a plain window with no UI elements except a close button and a browser frame so you can auth with the captive portal system, and goes away once connectivity is "restored".

How did you reach this conclusion?

At least with devices running iOS, if you let the charge drop to zero, and it loses its cached network settings, and then when you try to reconnect to your home wifi router, it will look for a file called

library/test/success.html at www.apple.com

which contains one line: Success.

If that file is missing, you will not be allowed to connect to your own home LAN, because Apple thinks you are behind a "captive portal". I redirect *.apple.com to stop iAd, ntp and other Apple crap even when I'm connected to the internet, so unlike the OP, this is a problem even when www.apple.com is not down for maintenance.

One solution is to redirect www.apple.com to your own httpd serving a local copy of /library/test/success.html.

In short, you are wrong. Redirect apple.com comains to your own httpd and read your logs.

There is lots of dialing home coming from iOS and indeed some of it will affect your ability to read content.

However, if that check fails, you'll only get a _notification_ "probably captive portal, you may want to login at yada yada" - instead of "Apple is down, no connectivity for you, nyah nyah".

Annoying, but not a showstopper.

You asked why so I answered. I didn't state a position about whether it should be doing it or not.

There are better ways to check connectivity. At least let it check multiple sites instead of only samsung.com .

Also, the answer is wrong. It does not just check connectivity, but downloads an XML file containing information on services that it is supposed to show.

You have to act more appalled by trivial annoyances, or you slow down the building of the whole hyperbole storm that the people here like to create. Otherwise, they are unable to distract themselves from the boredom and feelings of lack of empowerment in their lives.

Reply on news.ycombinator.com