captive portal detection in Thunderbird

Bryan Clark clarkbw at gnome.org
Mon Jun 27 23:02:19 UTC 2011


Hey -

I've been working on a Thunderbird add-on that tries to detect captive
portals <http://en.wikipedia.org/wiki/Captive_portal>.  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.
https://bugzilla.mozilla.org/show_bug.cgi?id=530878

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:
https://addons.mozilla.org/en-US/thunderbird/addon/thunderbird-captive-portal/
source: https://github.com/clarkbw/Thunderbird-Captive-Portal-Detector
static-url: http://clarkbw.net/lib/index.html

Cheers,
~ Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110627/55f6ea1f/attachment.html>


More information about the tb-planning mailing list