captive portal detection in Thunderbird

John Hopkins jhopkins at
Tue Jun 28 15:04:38 UTC 2011

Sounds really good, Bryan.  +1 on "run this captive portal check only 
when Thunderbird is having an issue connecting to it's intended network" 
due to the privacy concern you mentioned.

Just to throw another possibility out there, could you try and connect 
to a valid DNS name but on a server that isn't listening: If you get a 
response, then it must be a captive portal?  If you don't, there are 
other several possibilities (which would be the downside to this 
approach, but no privacy concerns).


On 11-06-27 04:02 PM, Bryan Clark wrote:
> Hey -
> I've been working on a Thunderbird add-on that tries to detect captive 
> portals <>.  For 
> Thunderbird (compared to Firefox) I think this is a fairly 
> straightforward problem to solve.  I wanted to talk a bit about my 
> solution to the problem and what issues still exist. I'm not sure if 
> this is something that could be merged into Thunderbird in the future 
> but I think that's a conversation that makes sense to have; it also 
> makes sense to have someone else write that code. ;-)
> I travel a decent amount and these kinds of pages always get in the 
> way of my using Thunderbird.
>     From my about:
>     *Captive Portals* are those redirect pages you get when you first
>     use the internet
>     connection at an airport or hotel or public wifi spot. Often a
>     captive portal is
>     requesting agreement to a Terms of Service and/or payment for usage.
>     *Thunderbird* doesn't currently detect Captive Portals well
>     because they are
>     designed to redirect web /HTTP/ traffic and not mail
>     /SMTP/POP/IMAP/. So if you
>     aren't using a web browser Thunderbird appears to not be able to
>     connect to your
>     email and until you browse the web you won't know why.
> *Current Solution*
> Here's some pseudo code to explain what happens.
>     for every (network online event or Thunderbird startup) {
>       open a (hidden) tab to a known static URL
>       if (URL is a redirect) {
>         show (hidden) tab
>       } else {
>         close (hidden) tab
>       }
>     }
> In other words I always open a tab to a known static URL but the tab 
> and it's related panel are collapsed so it doesn't appear inside 
> Thunderbird unless there was a redirect to another URL; at this point 
> the tab is shown and what is usually a captive portal page appears. 
>  If a captive portal ends up redirecting back to the static page I 
> close the tab and could possibly nudge Thunderbird into checking mail 
> at that point.
> *Background*
> I tried a couple different methods to solve this problem.  At first I 
> just created an HTTP request on my own and looked for a redirect, when 
> detected I tried to open a tab to that page. This solution didn't 
> handle the JavaScript or Meta-refresh type redirects that some APs 
> (access points) were using; often APs would respond as if they were my 
> static page but then rely on the browser to handle the redirect. 
>  Those kinds of redirects are a really poor way to implement the 
> captive portal system but I found a number of places doing just that.
> My second implementation was to examine the exact size of the response 
> given.  I took a hash of the index.html page and would download the 
> page via an HTTP request, then hash my download and compare.  This 
> worked fairly well except that if I needed to update the index.html 
> page for any reason my add-on would no longer work until my users had 
> a new version with a different hash.  Not a terrible problem but not 
> the kind of synchronization problem I want to deal with if I don't 
> have to.  Also this often required downloading the whole page before 
> you could safely examine it but it's possible you could optimize 
> against that with some kind of size comparison as well.
> Finally the overarching problem of each of these previous solutions 
> was that after a redirect was detected I then had to try to open a tab 
> which caused another redirect so I could get my users to login page 
> they needed to see.  By allowing a hidden tab to open a static page in 
> the background I end up showing the user a login page they need to 
> take action on and there's no waiting around for anything else.
> *Privacy*
> Obviously there can be privacy concerns with information collection as 
> I'm making a web call on the users behalf every time the network goes 
> up / down or Thunderbird is started.  However this is no different 
> than the Thunderbird start page and in fact I could attempt to use the 
> start page if I could know for certain that it would never be a 
> redirect; something I'm not sure it's being designed for.
> Data collection of redirect methods used.  At least as the feature 
> designer I'd like to get an idea of the type of redirections being 
> used (meta,js,dns,etc) and ask for further information if the 
> redirection detection wasn't successful.
> *Known Issues*
> JavaScript links are ignored in content tabs.
> Some login sites use the href="javascript:go();" style buttons which 
> have no action in Thunderbird content tabs.  I think this is due to 
> our tab content policy but it would be awesome if this was fixed for 
> this add-on and my google calendar tab add-on.
> *Possible Future*
> It might be possible to run this captive portal check only when 
> Thunderbird is having an issue connecting to it's intended network.  I 
> couldn't find a decent place to hook into this kind of response but 
> this would reduce not only the load on captive portal checks but 
> possible privacy concerns.
> There might be some more room to continue this feature by doing some 
> network diagnosis if we can't even get to our static URL we could try 
> helping the user with their network or VPN connection.
> *Bonus*
> It's a restart-less add-on so it's just a one click install and it's done.
> *Links*
> add-on: 
> source:
> static-url:
> Cheers,
> ~ Bryan
> _______________________________________________
> tb-planning mailing list
> tb-planning at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list