Re: Badly behaved captive portals

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

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

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

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.

Thanks for clarifying.

>Tobie, are you still intending to
>write up these use cases?

Absolutely. I will start working on those after the Coremob F2F in October.

>I feel like we're currently blocked on that
>and wonder if we can start to make progress in another direction, such
>as collating proposals.

Proposals are not in scope for this CG as per its charter. I think moving
the case studies document forward would be much more productive.

--tobie

Received on Monday, 24 September 2012 13:37:22 UTC