[HTTPS-Everywhere] HTTPS Everywhere for Chromium

[Daniel Lanigan]

Chris,

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, rentjungle.com, 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.

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.

Just sayin' :P


~ Daniel
On Dec 1, 2010 1:13 AM, "Chris Palmer" <chris at eff.org> wrote:
> 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
>
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101201/78e3542c/attachment.html>