Re: Badly behaved captive portals

I think we're going off in the wrong direction a bit. A captive
portal, as described by the spec, is one that issues a redirect to
http://10.0.0.1/pay-for-wifi or whatever. They only do this for http
urls, else they get the cert issue.

Being able to treat either of these cases as "offline" is a good idea
(which is what happens now with FALLBACK), even better if it were
optional (eg for genuine login redirects a la Gmail), even better if
we could feedback to the user that we'd detected a captive portal &
avoided it.

Anything that rewrites response content to display a portal without
issuing a redirect is an old problem, solutions to it should not be
appcache exclusive, therefore they're out-of-scope. Besides, I think
the solution is https.

On 24 September 2012 14:36, Tobie Langel <tobie@fb.com> 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. :)
>
>>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 14:32:24 UTC