Hey -<div><br></div><div>I've been working on a Thunderbird add-on that tries to detect <a href="http://en.wikipedia.org/wiki/Captive_portal">captive portals</a>.  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. ;-)</div>
<div><br></div><div>I travel a decent amount and these kinds of pages always get in the way of my using Thunderbird.  </div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>From my about:</div><div><br></div><div><span class="Apple-style-span" style="color: rgb(68, 68, 68); font-family: 'helvetica neue', arial, helvetica, sans-serif; font-size: 13px; line-height: 20px; background-color: rgb(255, 255, 255); "><b style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-size: 13px; vertical-align: baseline; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">Captive Portals</b> are those redirect pages you get when you first use the internet<br>
connection at an airport or hotel or public wifi spot. Often a captive portal is<br>requesting agreement to a Terms of Service and/or payment for usage.<br><br><b style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-size: 13px; vertical-align: baseline; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">Thunderbird</b> doesn't currently detect Captive Portals well because they are<br>
designed to redirect web <em style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-size: 13px; vertical-align: baseline; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">HTTP</em> traffic and not mail <em style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-size: 13px; vertical-align: baseline; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; background-position: initial initial; background-repeat: initial initial; ">SMTP/POP/IMAP</em>. So if you<br>
aren't using a web browser Thunderbird appears to not be able to connect to your<br>email and until you browse the web you won't know why.</span></div></blockquote><div><div><br></div><div><b>Current Solution</b></div>
<div><br></div><div>Here's some pseudo code to explain what happens.</div></div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><font class="Apple-style-span" face="'courier new', monospace">for every (network online event or Thunderbird startup) {</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">  open a (hidden) tab to a known static URL</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace">  if (URL is a redirect) {</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">    show (hidden) tab</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace">  } else {</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">    close (hidden) tab</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace">  }</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">}</font></div></div></blockquote><div><div><br></div><div>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.</div>
<div><br></div><div><b>Background</b></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><b>Privacy</b></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><b>Known Issues</b></div><div><br></div><div>JavaScript links are ignored in content tabs.</div><div><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=530878">https://bugzilla.mozilla.org/show_bug.cgi?id=530878</a></div>
<div><br></div><div>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.</div>
<div><br></div><div><b>Possible Future</b></div><div><br></div><div>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.  </div>
<div><br></div><div>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.</div>
<div><br></div><div><b>Bonus</b></div><div><br></div><div>It's a restart-less add-on so it's just a one click install and it's done.</div><div><br></div><div><b>Links</b></div><div><br></div><div>add-on: <a href="https://addons.mozilla.org/en-US/thunderbird/addon/thunderbird-captive-portal/">https://addons.mozilla.org/en-US/thunderbird/addon/thunderbird-captive-portal/</a></div>
</div><div>source: <a href="https://github.com/clarkbw/Thunderbird-Captive-Portal-Detector">https://github.com/clarkbw/Thunderbird-Captive-Portal-Detector</a></div><div>static-url: <a href="http://clarkbw.net/lib/index.html">http://clarkbw.net/lib/index.html</a></div>
<div><br></div><div>Cheers,</div><div>~ Bryan</div>