Also, I can't say I trust github's ssl given their latest "SSL Prevention Phase" blog post: <a href="https://github.com/blog/743-sidejack-prevention-phase-3-ssl-proxied-assets">https://github.com/blog/743-sidejack-prevention-phase-3-ssl-proxied-assets</a><br>
It's not actually ssl, as they put it, "The /<code>src/</code> attribute is rewritten to proxy through our normal asset servers so it **appears** to come from a secure source." All this does is fix the warning.<br>
<br><div class="gmail_quote">On Sat, Nov 13, 2010 at 5:05 PM, Robert Ransom <span dir="ltr"><<a href="mailto:rransom.8774@gmail.com">rransom.8774@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Sat, 13 Nov 2010 13:51:25 -0800<br>
<div class="im">Peter Eckersley <<a href="mailto:pde@eff.org">pde@eff.org</a>> wrote:<br>
<br>
</div><div class="im">> It's worth noting that in a use case like this, HTTPS Everywhere is equivalent<br>
> to HSTS:<br>
><br>
> <a href="https://secure.wikimedia.org/wikipedia/en/wiki/Strict_Transport_Security" target="_blank">https://secure.wikimedia.org/wikipedia/en/wiki/Strict_Transport_Security</a><br>
<br>
</div>No.  sslstrip can easily be extended to remove<br>
Strict-Transport-Security headers from responses that it forwards to the<br>
client (if it does not do so already).<br>
<font color="#888888"><br>
<br>
Robert Ransom<br>
</font><br>_______________________________________________<br>
HTTPS-everywhere mailing list<br>
<a href="mailto:HTTPS-everywhere@mail1.eff.org">HTTPS-everywhere@mail1.eff.org</a><br>
<a href="https://mail1.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://mail1.eff.org/mailman/listinfo/https-everywhere</a><br>
<br></blockquote></div><br>