Re: Badly behaved captive portals

>>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.

Since an element of the design strategy behind the current appcache
spec is intended specifically to cope with captive portals 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.

-- 

------------------------------
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.

Received on Friday, 21 September 2012 15:53:50 UTC