- From: Tobie Langel <tobie@fb.com>
- Date: Fri, 21 Sep 2012 16:46:47 +0000
- To: Andrew Betts <andrew.betts@ft.com>
- CC: "public-fixing-appcache@w3.org" <public-fixing-appcache@w3.org>
On 9/21/12 5:53 PM, "Andrew Betts" <andrew.betts@ft.com> wrote: >>>However, today we've been looking at the possibility that a captive >>>portal simply returns a login page on the URL you requested rather >>>than returning a redirect. It wouldn't be good practice, but it would >>>be technically feasible. In that situation, potentially our user will >>>get the captive portal page appearing in our app, and will have to - >>>rather ironically - turn off their network connectivity in order to >>>get the app to work. >>> >> Isn't this issue orthogonal to AppCache, and isn't the only mitigation >> strategy to use SSL? > >No, I don't see it that way. Captive portals are rarely incompetent >enough to allow SSL traffic without login (otherwise we'd all be >leeching free wifi), so they would likely just intercept it and return >the login page anyway, despite the certificate errors that would >result from that. In addition, users typically don't start their >session on SSL - I type gmail.com, and Google redirects me to https. >By then I've already hit the captive portal. I was referring to the case where the user is already on https://gmail.com and XHR requests hit the portal instead of a redirect. >Since an element of the design strategy behind the current appcache >spec is intended specifically to cope with captive portals My understanding is its not so much coping with captive portals as it is avoiding malicious behavior. >it seems >sensible to ensure that we capture that use case when considering any >possible improvement or replacement to appcache. I think this covers >it: > >- A user is in a hotel lobby and connects to the WiFi, not knowing if >it is free or not. They use a homescreen shortcut to launch a >previously saved web app, hoping it will work. But the hotel wifi is >serving a captive portal login page in response to every request. >Nevertheless, the user sees the app start and is able to use the >offline features. How can you possibly mitigate this without relying on https? --tobie
Received on Friday, 21 September 2012 16:47:14 UTC