Re: Badly behaved captive portals

On 21 Sep 2012, at 17:46, Tobie Langel wrote:

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

I can immediately think of two ways:

1) if I had a proxy/controller type thing, I'd be able to inspect the response, see it was not what I expected, and fish something out of localstorage instead.
2) if I had a way of doing fallbacks without a network check first, I could configure those in the manifest for the entry point URLs, and avoid any risk of captive portal interception

I was trying not to presuppose what the solution to this might look like, but I think given that at least two possible solutions use direct features of appcache or its replacement, it seems right to capture this use case as part of the objectives for appcache.
-- 

------------------------------
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 17:20:40 UTC