Portal detection broken

[zach-klippenstein]

Portal detector starts, log shows which portal detector implementation is being used, then fails to detect the portal.

Confirmed at Canadian Starbucks.

[zach-klippenstein]

Figured out why my captive portal detection app wasn't working at Starbucks hotspots. I'm using Apple's page to check for proxies, which consists of a single line of simple HTML. Before signing in, all my browsers and a REST tool I grabbed off the Play store returned the Starbucks terms of service acceptance page. My detector, however, returned the page as expected when not behind a portal, with one difference: it included a W3C prefix. Upon further inspection, the response headers also showed it was coming from a Microsoft IIS server - probably not what Apple is using to serve their pages. Those headers were also missing from a known correct response. I had thought at first my HTTP client might be locally caching the "success" response, but that obviously wasn't the problem.

Then I noticed I had, for some reason early on (about a year ago), decided to use the following user agent string in my request: CaptiveNetworkSupport/v1.0 wispr. I think the site I read explaining how iOS devices detected portals mentioned that they used this user agent string, and I thought it would be a good idea to do the same - couldn't hurt. Well, I was wrong. Turns out, the price Starbucks is using returns a fake success page to any clients using that user agent string. This only started about a month ago, when my detection app started malfunctioning, and I also noticed my Macbook was no longer popping up the acceptance page either.

I removed the user agent string, and the expected page was returned. Does anyone know why Starbucks is trying to actively fake out iOS devices?