Re: Badly behaved captive portals

>>>> - 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.
>
> How can you see the response was not what was expected? The portal could
> very well make the request on your behalf and inject extra content in it
> (like adds, for example).

That's true, and is possibly worthy of separate consideration, but
this particular use case was not concerned with security.  The use
case is that the user gets a reliable start-up experience while their
connection is trapped by a captive portal.  My proxy/controller could
quite easily establish whether we were looking at a portal login page.

>
>>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
>
> Agreed, that's the Chromium's INTERCEPT feature, which I think is a great
> add on, but which doesn't protect you from the kind of issue you're
> talking about. Only removing FALLBACK would help you there.

Intercept is a potential solution, but I'd be concerned that it can't
quite work here - the web app the user has saved will be a root URL,
so eg. http://www.example.com/ is saved.  In order to get that to
trigger an intercept, I'd need to state / as the namespace for the
interception resource.  And that means bye bye network for my entire
domain, surely, because the namespace is a prefix.  Having said that
my understanding of INTERCEPT is limited to the Google Code issue
description.

I don't get why removing FALLBACK will help.

I do think this thread has got to the point of proving that my use
case is valid and this issue is not orthogonal to app cache :-)

Andrew

-- 

------------------------------
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:54:19 UTC