<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    John<br>
    <br>
    <br>
    On 11-06-27 04:02 PM, Bryan Clark wrote:
    <blockquote
      cite="mid:BANLkTinL=p=c_xZTcP9174FpxxysFSTqbw@mail.gmail.com"
      type="cite">Hey -
      <div><br>
      </div>
      <div>I've been working on a Thunderbird add-on that tries to
        detect <a moz-do-not-send="true"
          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 moz-do-not-send="true"
            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=<a class="moz-txt-link-rfc2396E" href="javascript:go();">"javascript:go();"</a> 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 moz-do-not-send="true"
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 moz-do-not-send="true"
          href="https://github.com/clarkbw/Thunderbird-Captive-Portal-Detector">https://github.com/clarkbw/Thunderbird-Captive-Portal-Detector</a></div>
      <div>static-url: <a moz-do-not-send="true"
          href="http://clarkbw.net/lib/index.html">http://clarkbw.net/lib/index.html</a></div>
      <div><br>
      </div>
      <div>Cheers,</div>
      <div>~ Bryan</div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>