1. 15
  1.  

  2. 7

    Great idea—I’ve always just used my personal website for this, now I have one more reason to SSL it :)

    1. 4

      This seems very similar to the generate_204 page from Google: http://clients3.google.com/generate_204

      http://stackoverflow.com/questions/1989214/google-com-and-clients1-google-com-generate-204

      In the event that Chrome detects SSL connection timeouts, certificate errors, or other network issues that might be caused by a captive portal (a hotel’s WiFi network, for instance), Chrome will make a cookieless request to http://www.gstatic.com/generate_204 and check the response code. If that request is redirected, Chrome will open the redirect target in a new tab on the assumption that it’s a login page. Requests to the captive portal detection page are not logged.

      I discovered this is how Android devices generally detect captive portals on free wifi networks.

      1. 3

        MacOS does something similar right inside the WiFi stack and pops up a web view modal for the portal login if detected (specifically, /System/Library/CoreServices/Captive Network Assistant.app).

        It uses http://captive.apple.com/hotspot-detect.html, or http://www.apple.com/library/test/success.html in 10.9 or older. (No idea why it changed… maybe they want to HSTS the domain eventually?)

      2. 1

        Why use this over example.com?

        1. 1

          Nice to have a neutral alternative to those pages mentioned in comments.