Re: Badly behaved captive portals

On 24 Sep 2012, at 14:36, Tobie Langel wrote:

> On 9/24/12 2:40 PM, "Andrew Betts" <andrew.betts@ft.com> wrote:
> 
>>> Let's not get hung-up on syntax here.
>> 
>> Isn't the rest of your message almost entirely about syntax?
> 
> Yes, that was to provide example of why syntax wasn't an issue. :)

I see.  Sort of.

> 
>> Anyway, whatever it is that solves this problem, I say it's a problem
>> that needs solving and is in scope.
> 
> I'm sorry if I sounded dismissive, certainly wasn't my intent. I'm just
> trying to get a good understanding of the problem and have utterly failed
> at doing so, so far.

No problem - I want to make it clear that I'm using specific examples and suggesting solutions simply as a means of explaining the problem, not because I'm actually advocating those solutions.

> 
> Let me walk you through how I understand this issue and please point out
> the parts I'm misunderstanding.
> 
> 1. User opens his browser. He's on a network using DNS spoofing to create
> a captive portal.
> 
> 2. User navigates to a URL. If he is using the https protocol the User
> agent sees there's a digital certificate mismatch and alerts the user. The
> browser can offer different options to the user in that case, all of
> which are out of scope of this group (and of spec-land in general).

I say the problem here is still in scope, though a solution probably isn't.  Specifically, a native app can load, make an HTTPS network request, get a certificate mismatch, and handle that in the application.  Result is I see no errors and the app works as if I'm offline (which to all intents and purposes, I am).  In the web world, currently we can't control this behaviour and the user ends up with a far poorer user experience than they would get with native - they get a browser dialog or page reporting a certificate error.

There may well be no practical way of solving this in the case of HTTPS, and it's not a practical issue for FT currently as we don't serve many of our requests over HTTPS.  Suffice to say I don't see HTTPS as a solution, because it replaces one bad experience with another, but I don't care about it as much either.

> 
> 3. If he's not using https, the browser cannot discover the spoof. So the
> issue becomes an application-level one.
> 
> a) If the request is made through XHR (e.g. Main Entry served from cache,
> calls to API), application code can check that the response returned is
> sound.
> 
> b) If there exists a hypothetical, application-level proxy system that
> intercepts all navigation to the same domain, then again, the application
> could inspect that request and decide what to do with it.
> 
> Is your suggestion something along the line of:
> 
> In case a solution to build a JS proxy is developed, application code
> should be able to inspect top level responses within the same domain
> before displaying them to the user (notably to verify, when not using
> https, that a user is not captive of a DNS spoofing portal) and cancel
> navigation altogether.

Potentially, though the INTERCEPT method of the app cache may be more practical as a solution since it is already specified and partly implemented.

The actual scenario we are concerned about is this:

1. User goes to app.ft.com/ having previously fully cached the app.  
2. Browser requests page from network because the URL is not explicitly cached.
3. Captive portal serves a login page (over HTTP)
4. Browser renders the login page
5. User must activate airplane mode or leave the wifi zone and refresh before the app will work again.

What we would prefer to happen is:

1. User goes to app.ft.com/
2. App cache serves a controller page without going to the network
3a. We make some AJAX requests, conclude that responses are invalid, and switch into an offline state; or
3b. We make some AJAX requests, which work, and we proceed assuming we are online.

INTERCEPT seems like a perfect solution to this for article URLs which have a common namespace that doesn't capture anything else, but doesn't work well for the root URL.  For that, you couldn't set up an intercept namespace without intercepting every request to the entire domain, so you would have to make a special case for the root URL and explicitly cache it, which creates a separate cache entry that is nevertheless probably identical to the intercept resource.  It's also true that if you are forced to app cache the homepage, you're going to struggle to serve timely content on it for crawlers and devices that don't support app cache.  I'd rather have an intercept that *maps* that URL to some other resource.

Frankly, designing a good solution here is probably beyond my abilities, and is in any case out of scope.  I just feel the use case is valid.

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 Monday, 24 September 2012 14:45:02 UTC