<div dir="ltr">Firstly, the same issue would occur with mixed display content, if blocking of mixed display content was turned on, right?<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">So the issue here is simply that, to the extent that the mixed content blocker blocks _any_ requests, it does so before the requests are processed by HSTS or extensions.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">The first thing to do is to get some decent documentation on how things work now – EFF and Mozilla, I’m looking at both of you! That means documentation for users, extension developers and website developers. Especially website developers, since the ultimate aim is to have the websites fixed so there is no mixed content in the first place.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Then we can ask the browser publishers to change their designs. Yes, they should change their designs. But I’m not sure that I agree with what the change should be.<br>
<br></div><div class="gmail_extra">Firstly, whichever order the various components (mixed content blocker, HSTS, extensions) process the request in, it should be clear to the user what that order is. Especially when that user is an HTTPS Everywhere ruleset author. :) [1]<br>
</div><div class="gmail_extra"><br>I’m inclined to say that the mixed content blocker should block the requests before they are processed by HSTS or extensions, but the user should be able to override this. It should be possible, via the normal user interface (not just something buried in about:config), to make this override permanent. This seems like the way to get website developers’ attention while allowing users to get the same benefits that they did before the mixed content blocker was introduced.<br>
<br></div><div class="gmail_extra">(Of course, the user should also be able to turn off the mixed content blocker entirely, but that’s probably a separate issue.)<br></div><div class="gmail_extra"><br>[1] <a href="https://lists.eff.org/pipermail/https-everywhere/2014-January/001897.html">https://lists.eff.org/pipermail/https-everywhere/2014-January/001897.html</a><br>
<br clear="all"><div><div dir="ltr"><div>--<br>Brian Drake<br><br>All content created by me: <a href="http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html" target="_blank">Copyright</a> © 2014 Brian Drake. All rights reserved.<br>
</div></div></div>
<br><div class="gmail_quote">On Tue, Jan 14, 2014 at 0910 (UTC), Jacob Hoffman-Andrews <span dir="ltr"><<a href="mailto:jsha@newview.org" target="_blank">jsha@newview.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Brian, you are correct: Currently in both Chrome and Firefox, neither HSTS nor HTTPS Everywhere can<br>
"fix up" active mixed content. The blocking happens before either mechanism has a chance to rewrite<br>
the URLs.<br>
<br>
<br>
Here are the relevant tickets to allow HTTPS Everywhere to do the rewrite, please star / vote for them:<br>
<br>
  <a href="https://code.google.com/p/chromium/issues/detail?id=122548" target="_blank">https://code.google.com/p/chromium/issues/detail?id=122548</a><br>
  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=878890" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=878890</a><br>
</blockquote></div></div></div></div>