[HTTPS-Everywhere] HTTPS Everywhere for Chromium

Chris Palmer chris at eff.org
Tue Nov 30 22:13:37 PST 2010


Ha Ha Only Serious:

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?)

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?

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").


On Nov 30, 2010, at 6:47 PM, Peter Eckersley wrote:

> Adam, I still haven't had as much time as I would like to go over this, but
> cursorily it looks very promising.  
> 
> As you noticed, the two most complicated cases seem to be Wikipedia and Google
> Search.  We now have 350 rulesets, but I don't think any of the others exhibit
> genuinely complex rewriting behaviour.
> 
> I think we could handle Wikipedia under your proposal by enumerating all of
> the langugaes wikipedia supports.  Although that might be several thousand
> entries in your rule format if one supported
> wik(ipedia|inews|isource|ibooks|iquote|iversity|tionary) for each language :(.
> Would parsing so many rules be a load-time performance problem?  
> 
> Can SPDY or something else fix the the Google search case?
> 
> On Fri, Nov 26, 2010 at 11:55:34AM -0500, Adam Langley wrote:
>> At the moment I don't believe that any of the experimental Chromium
>> extension APIs[1] are sufficient to support HTTPS Everywhere and that
>> there aren't any other plans to support it in Chromium.
>> 
>> In order to support HTTPS Everywhere in Chromium we have to live with
>> some limitations which don't affect Firefox:
>> 
>> 1) Chromium will not let extensions excessively slow down normal
>> execution. That means that it won't perform a round-trip to an
>> extension process for each URL request in order to allow the extension
>> to manipulate the request.
>> 
>> 2) Serialising and re-parsing URLs is very scary from a security point
>> of view. It would be greatly preferable to handle URLs in their
>> processed form.
>> 
>> 3) I'm not going to put a regexp engine into the Chromium networking
>> stack for complexity reasons.


-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation




More information about the HTTPS-everywhere mailing list