What are the pros and cons of HTTPZ when compared to HTTPS Everywhere?

[turtlshell]

I stumbled across your add-on over on Reddit and I wanted to know what the benefits / drawbacks are of HTTPZ vs HTTPS Everywhere. This thread, while old, seems to suggest that HTTPS Everywhere isn't exactly perfect. No idea if the contents of what it mentions still stand or not, but regardless, I'm curious as to whether I should swap to HTTPZ.

Thanks in advance!

[Mikaela]

I think https://github.com/claustromaniac/httpz/issues/8 may answer you.

[turtlshell]

That is quite helpful as to showing how HTTPZ isn't really vulnerable to MITM attacks, thanks :) however, it doesn't really outline as many positives / negatives as I assume there are in reality. I could of course be wrong.

[claustromaniac]

Summarizing, HTTPZ automatically determines whether a site supports HTTPS or not, whereas HTTPS Everywhere (which I will refer to as HTTPS-E from here on) uses an internal set of predefined rules.

Advantages of HTTPZ:

• Has a significantly smaller memory footprint. HTTPS-E uses over 20 MB of RAM, whereas HTTPZ requires less than 300 KB.
• It does not miss many opportunities to connect to sites over HTTPS. It is practically impossible for HTTPS-E to have rules for every site in the Internet. Even if it managed to have them, those rules would never be fully up-to-date in practice, because changes would need to be reported by a human, and then the ruleset would need to be updated by another human, and then your copy of HTTPS-E would have to download the ruleset for those changes to take effect in your browser (which thankfully does not happen all the time).

Disadvantages of HTTPZ:

• The two known issues in the description.
• The extension finds out if a server supports HTTPS literally by trial and error, which means that for servers that do not support HTTPS, you're doing something that most of their other users likely don't do. This can make you stand out a bit, but this is not a completely bad thing because you're indirectly telling those servers' operators that you want to connect over HTTPS. I've seen quite a few sites start supporting HTTPS since I started using this extension. I'll never know if that really had anything to do with my failed attempts at connecting over HTTPS, but it remains a possibility.
• Requests to some sites that don't support HTTPS will not fail immediately, they can take a while to time out (which means you have to wait a while for the extension to redirect to HTTP). I have an idea to make this more tolerable, but I haven't tried it out yet.
• Some sites that support HTTPS use weak encryption. This could lead to a scenario of users getting a false sense of security from the extension when they are doing something of critical importance that requires the best security available (because the presence of the padlock is often enough to earn their trust). This is not just a downside of this extension though, every extension that tries to achieve the same shares this downside (including HTTPS-E). Ideally, users should never blindly trust sites just because they're served over HTTPS, but teaching and/or reminding users of that is well beyond the scope of this extension. Not to mention that we web extension developers are very limited in what we can do anyway...

I may be missing one or two things, but I hope that helps a bit.

[claustromaniac]

Ah.. I just remembered another disadvantage: some sites support HTTPS only over a different hostname (like http://example.com and https://secure.example.com). These are not common in my experience, but HTTPZ can't handle those for obvious reasons. HTTPS-E correctly redirects those to HTTPS (when there are rules for them in the ruleset).

[turtlshell]

That clears everything up, thanks a lot :+1:

[claustromaniac]

I think it's not an issue with the extensions themselves. Modern browsers tend to disable weak cyphers and algorithms, or warn user about them.

True, that was more of a problem a few years ago. Nowadays Firefox shows a different lockpad icon for unsafe negotiations of keys, mixed content, and other risky scenarios.

So, the best approach would be leaving both HTTPS-E and HTTPZ enabled? How well do they work together at the same time?

Using both at the same time is not something their respective developers (me included) aim to support. I developed this as an alternative to HTTPS-E, so I've never tested them together to see if there are any issues.

That being said, I don't know if this extension can interfere with HTTPS-E in detrimental ways because I didn't give that extension's source code a good look, but I would find it very unlikely for HTTPS-E to interfere with HTTPZ. If you do try to use them together and you notice any issues, let me know. If you don't notice any issues, it's safe to assume there are no issues.