[HTTPS-Everywhere] more rules mean more time

Russell Golden niveusluna at niveusluna.org
Tue Mar 12 07:49:43 PDT 2013


ARGH. WHY does the admin of this list think it's a good idea to not set the
reply-to to the address of the list? And don't say "violation of
standards," I want something sensible.

On Mar 8, 2013 5:34 PM, "Peter Eckersley" <pde at eff.org> wrote:
>
> Adding more rulesets does not slow the browser down.  The algorithm for
> querying them is O(1).

That is very interesting. I did not know that. I am a newbie programmer. I
would like to know how the heck that is possible, let alone able to be
coded. It sounds *very* useful.

> On Thu, Mar 07, 2013 at 11:07:18PM -0600, John A. Wallace wrote:
> > Why would it not be preferable to have an ad hoc
> > approach such as one that "on the fly" determines whether another SSL
> > website exists and then simply have the browser switch to it and right
that
> > rule into "this" browser since it would, in all likelihood, be one to
which
> > "this user" returns at some time, instead of pushing these rules off
into
> > every browser be default? No doubt I am overlooking some important
> > consideration, but it seems curious to me nevertheless.
You are overlooking one, yes. And it is not obvious, so don't feel bad
about it. Other extensions have tried this approach on different browsers,
and they all have the same problems that HTTPS Everywhere tries to avoid.

Not all websites that support SSL do so on the same domain as their
unencrypted site. The trend with this seems to be that this is only done
for testing (encrypted.google.com, secure.wikimedia.org/wikipedia), and is
rolled out to the main domain when it is deemed stable enough. However, it
still causes issues with on-the-fly detection.

If your extension automatically probes subdomains, then you don't know that
you will actually be going to the same site. This is true of all domains,
actually, not just subdomains.

Then there is another problem: not all sites that support SSL are available
*entirely* over SSL. Barnes and Noble seems to have this problem. Only part
of the site is available encrypted. If this is the case, then they're Doing
It Wrong, and I cannot fathom how that could be easier than just making the
entire site available, but it happens more often than you would think.
Sadly.

This is why HTTPS Everywhere has rulesets that explicitly cover only
certain directories or contain exclusion rules, instead of just containing
a list of domains.

Russell Golden
Fedora Project Contributor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20130312/56838e70/attachment.html>


More information about the HTTPS-everywhere mailing list