Re: Badly behaved captive portals

On 9/24/12 4:46 PM, "Andrew Betts" <andrew.betts@ft.com> wrote:

>On 24 Sep 2012, at 15:31, Jake Archibald wrote:
>
>> 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.
>
>OK, point taken.

Sounds like we've just gone full circle here[1].

I propose the following RESOLUTION:

"DNS spoofing captive portals are a usability and security issue well
beyond AppCache. It is therefore outside of the scope of this CG to cater
for them."

Please voice any objection you might have to this resolution.

Thanks,

--tobie

---
[1]: 
http://lists.w3.org/Archives/Public/public-fixing-appcache/2012Sep/0030.htm
l

Received on Monday, 24 September 2012 16:11:53 UTC