Re: Badly behaved captive portals

> Lanyrd uses Twitter for logins, but we don't redirect there, we
> provide a login link for the user to click. We never wanted to do
> login redirects, but yeah, appcache means we can't. Gmail DOES 302 to
> another domain for logins, so yes, we should add this as a use-case.

Hadn't considered whether we were capturing the redirect use case, but yes, agreed. 

> 
> If you're on a network that can make a captive portal redirect, they
> can also inject content into HTTP responses (cookies, ads). Appcache
> may exacerbate the issue by persisting it, but the 'attacker' can
> already do something very similar with the standard cache. This isn't
> a new issue & the solution is HTTPS.
> 
>> 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.
> 
> Hmmm, this creates a new security issue. Imagine you visit my evil website...

Yes, I was just listing possible solutions in response to Tobie's 'how could you possibly do this' comment, and I agree that one has some particular drawbacks :-)   

All I want to do is capture the interfering captive portal use case.  The point is, native apps don't have this problem.  Once installed, a native app could be launched offline and render a UI without any network requests, then attempt a network request for a content update, and get a login page back from a captive portal.  It wouldn't understand it, so would (hopefully) handle it gracefully and tell the user they were offline.

I suspect the web solution is some form of the INTERCEPT idea.  But I still don't see any way within the current proposal that a root URL could be intercepted while other URLs on the same domain are not, because the INTERCEPT syntax would treat '/' as a prefix.


-- 

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