<p>Chris,</p>
<p>While I do agree in principal, it's just not going to happen yet. I'm working on getting https going for my company's site, <a href="http://rentjungle.com" target="_blank">rentjungle.com</a>, but I'm having issues with getting the CDN working correctly (I'm not sure it's possible with our current setup). However, the real issue lies with smaller sites, especially personal websites running on shared servers. Dreamhost, for instance, requires you to have a unique IP address (and of course, the certificate), which obviously costs more. <br>

</p><p>So, while it's not a good thing really, https is pretty far from being the primary protocol. But, that's not to say that _every_ corporately owned website, especially those that require a user account, should not be using https.</p>

<p>Just sayin' :P</p><p><br></p><p>~ Daniel<br></p>
<div class="gmail_quote">On Dec 1, 2010 1:13 AM, "Chris Palmer" <<a href="mailto:chris@eff.org" target="_blank">chris@eff.org</a>> wrote:<br type="attribution">> Ha Ha Only Serious:<br>> <br>> HTTPS Everywhere is good and obviously I like it, but really it is a workaround for bad behavior in browsers which affords bad behavior in servers. It's like if PuTTY took your password and then first tried telnet before SSH ("after all, SSH is expensive and slow"). (Fun game: how many IM and email clients actually do that?)<br>


> <br>> Someday, Chrome will be trying SPDY first before HTTP and HTTPS, right? This protocol reboot is our chance to fix the default from "goaty" to "minimally safe". Is it a better use of our time to add SPDY support to as many servers and clients as we can, than to emulate HTTPS Everywhere in a Chrome that was not made to support it?<br>


> <br>> The sooner browser vendors start deprecating HTTP, the better. They can deprecate HTTP in the UI (instead of a warning or notification about the site being secure, why not a warning or notification about the site being insecure? I use the terms "warning" and "notification" as in Faith Cranor's "Framework for Reasoning about the Human in the Loop"), and they can deprecate in the networking stack ("Trying SPDY... failed. Trying HTTPS... failed. Trying Gopher... failed. Trying FTP... failed. Falling back to HTTP... success. Note to webmasters: For high performance, consider enabling SPDY or HTTPS").<br>


> <br>> <br>> On Nov 30, 2010, at 6:47 PM, Peter Eckersley wrote:<br>> <br>>> Adam, I still haven't had as much time as I would like to go over this, but<br>>> cursorily it looks very promising.  <br>


>> <br>>> As you noticed, the two most complicated cases seem to be Wikipedia and Google<br>>> Search.  We now have 350 rulesets, but I don't think any of the others exhibit<br>>> genuinely complex rewriting behaviour.<br>


>> <br>>> I think we could handle Wikipedia under your proposal by enumerating all of<br>>> the langugaes wikipedia supports.  Although that might be several thousand<br>>> entries in your rule format if one supported<br>


>> wik(ipedia|inews|isource|ibooks|iquote|iversity|tionary) for each language :(.<br>>> Would parsing so many rules be a load-time performance problem?  <br>>> <br>>> Can SPDY or something else fix the the Google search case?<br>


>> <br>>> On Fri, Nov 26, 2010 at 11:55:34AM -0500, Adam Langley wrote:<br>>>> At the moment I don't believe that any of the experimental Chromium<br>>>> extension APIs[1] are sufficient to support HTTPS Everywhere and that<br>


>>> there aren't any other plans to support it in Chromium.<br>>>> <br>>>> In order to support HTTPS Everywhere in Chromium we have to live with<br>>>> some limitations which don't affect Firefox:<br>


>>> <br>>>> 1) Chromium will not let extensions excessively slow down normal<br>>>> execution. That means that it won't perform a round-trip to an<br>>>> extension process for each URL request in order to allow the extension<br>


>>> to manipulate the request.<br>>>> <br>>>> 2) Serialising and re-parsing URLs is very scary from a security point<br>>>> of view. It would be greatly preferable to handle URLs in their<br>


>>> processed form.<br>>>> <br>>>> 3) I'm not going to put a regexp engine into the Chromium networking<br>>>> stack for complexity reasons.<br>> <br>> <br>> -- <br>> Chris Palmer<br>


> Technology Director, Electronic Frontier Foundation<br>> <br>> _______________________________________________<br>> HTTPS-everywhere mailing list<br>> <a href="mailto:HTTPS-everywhere@mail1.eff.org" target="_blank">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></div>