Re: Badly behaved captive portals

On 9/21/12 1:13 AM, "Andrew Betts" <andrew.betts@ft.com> wrote:

>The app cache spec envisions the possibility of a captive portal (a
>WiFi hotspot login page) being returned by a network rather than the
>resource requested, and therefore considers an HTTP redirect response
>to be an indication that the connection is offline for the purposes of
>choosing to serve a fallback from cache rather than the response from
>the network.
>
>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.
>
>1. Does anyone see a solution to this within the current app cache
>spec / implementation?
>2. In practice has anyone ever encountered a captive portal that
>behaves like this?
>3. Do we care about this use case?
>4. If so, is it on the list (tobie?)

Isn't this issue orthogonal to AppCache, and isn't the only mitigation
strategy to use SSL?

--tobie

Received on Friday, 21 September 2012 12:56:51 UTC