❌ Software Removal | replace HTTPS Everywhere with HTTPZ

[atomGit]

HTTPS Everywhere is not an optimal solution IMO - it relies on a massive list which is not always accurate, as well as human feedback

furthermore, apparently virtually none of these http>https add-ons work when FPI is enabled and isolation is a very necessary function for those wanting to protect their privacy

HTTPZ does not rely on lists and will fallback to http as necessary - it works with FPI also - install it, forget it - no configuration needed (the dev is part of the ghacks project - great guy)

[ThatLurker]

HTTPZ GitHub: https://github.com/claustromaniac/httpz

[Mikaela]

HTTPS Everywhere's view on relying on whitelist: https://www.eff.org/https-everywhere/faq/#why-use-a-whitelist-of-sites-that-support-https-why-cant-you-try-to-use-https-for-every-last-site-and-only-fall-back-to-http-if-it-isnt-available

[atomGit]

not sure what you wish to add by referring to the EFF explanation, but in general i'm not seeing where it makes a lot of sense relative to HTTPZ which works very differently than HTTPS-E

HTTPZ doesn't 'test' if a site is accessible using https - it interrupts the http request and resubmits an https one, falling back to http depending on factors which you'd need to ask the developer about for more clarity

as for the comment "Falling back to insecure HTTP isn't safe", sure, but some sites simply cannot be accessed via https - doesn't HTTP-E fall-back to http also when necessary (it certainly should not block access entirely)?

the only issue i see with with HTTPZ is, as the dev says, "Unlike HTTPS Everywhere, this extension doesn't take care of sub-requests triggered from HTTP-only sites."

the biggest advantage is that HTTPZ never guesses - it will always try https before falling back and therefore the infrastructure to maintain lists (which are not always accurate) is avoided

that said, i have no important, overriding reason to oust HTTP-E - i simply much prefer HTTPZ for reasons stated, and i'm familiar with the developer

[Mikaela]

I don't know if you have noticed, but now there is also a suggestion to replace HTTPS Everywhere with Smart HTTPS (https://github.com/privacytoolsIO/privacytools.io/issues/810). Are you familiar with it or how does it compare?

[atomGit]

if you're addressing me, i would recommend HTTPZ for reasons given in my previous comment - it's simple, it works and i know the dev

i've used both HTTPS Everywhere and Smart HTTPS - the former i dumped rather quickly because relying on out of date and inaccurate lists is totally not the way to go IMO - the latter is better because it works automatically in a similar way to HTTPZ, but it does not (or did not) work with FPI (or containers - i forget which) and it never deletes the whitelist entries which i didn't like

HTTPZ is so much simpler and lighter and it just works

[atomGit]

ps: not sure HTTPS Everywhere works with FPI (privacy.firstparty.isolate) - you'd have to verify because it's really important that the http>https extension works with FPI

[jonaharagon]

it will always try https before falling back

This is the issue with HTTPZ, and why I think HTTPS Everywhere's whitelist solution is the more secure option, even if it isn't as comprehensive. I haven't seen any evidence that HTTPZ has any kind of downgrade attack prevention.

For example, if I was an attacker in between a client and a webserver, say privacytools.io, I could block HTTPS access to https://privacytools.io, by blocking port 443 or whatever...

• From what I can tell, HTTPZ would just say "this resource isn't available over HTTPS" and happily load http://privacytools.io, because it has no way of knowing if the site should be loaded over HTTPS.

• On the other hand (assuming privacytools.io is in the whitelist), as far as I understand it, HTTPS Everywhere will see that access to https://privacytools.io is blocked (by the MITM) and not allow any connections over HTTP, because it knows that privacytools.io needs to be loaded over HTTPS. That's the entire point of the whitelist which I think is what is being missed in this thread.

Yes, HTTPZ may upgrade more connections to HTTPS, which is cool and all, but it doesn't prevent downgrade attacks which is a security flaw. This is the same issue I brought up when recommending to close https://github.com/privacytoolsIO/privacytools.io/issues/810#issuecomment-478799835.

---

As an aside, this is of course, the exact same thing @Mikaela brought up in the linked article, I just feel like we weren't addressing it:

https://www.eff.org/https-everywhere/faq/#why-use-a-whitelist-of-sites-that-support-https-why-cant-you-try-to-use-https-for-every-last-site-and-only-fall-back-to-http-if-it-isnt-available

Also, it's not possible to test for HTTPS in real time without introducing security vulnerabilities (What should the extension do if the HTTPS connection attempt fails? Falling back to insecure HTTP isn't safe).

[2c00l2bsh4r3d]

For what it's worth, neither Smart HTTPS nor HTTPZ touch any https requests, as far as I can tell. For example, when you click on a link with an https src, or when you manually enter 'https' in the urlbar, they don't mess with those requests. When such requests fail, these extensions don't downgrade them. They only downgrade in the scenario of a failed attempt at redirecting http to https. Smart HTTPS explicitly states this behaviour in its documentation. HTTPZ's documentation doesn't specifically mention this, but it makes this behavior pretty obvious by consistently showing an icon in the urlbar every time it redirects a request.

In other words, these extensions' philosophy is something like "you were gonna visit this site over http in the first place, so you shouldn't care if I downgrade this request to http after the attempt over https fails", but they respect you and your browser whenever you try to connect over https to begin with.

Therefore, in my humble opinion, these extensions' behavior doesn't introduce any vulnerabilities. They're not opening any new holes. Using Firefox+HTTPZ/Smart HTTPS is still safer than using Firefox without any extensions. HTTPS-E may not be vulnerable to the so-called "downgrade attacks" by a MitM, but that's a plus, not a given. You can also avoid many MitM attacks by encrypting DNS traffic (with DNSCrypt), and that would also be a plus.

Bottom line, they all have their pros and cons, but IMHO that's about it.

[blacklight447]

So far I see no real case to make add smart https or httpz to privacytools.io, or let them replace https everywhere. Anyone okay with me closing this issue

[Mikaela]

I am okay and can close it.

[atomGit]

wanted to make a correction - i said...

not sure HTTPS Everywhere works with FPI (privacy.firstparty.isolate)

pretty sure the problem was with the Temporary Containers add-on, not FPI - i know there was a problem with containers and one or more of the http>https add-ons - i know the http upgrade add-on i was using was affected and i think it was Smart HTTPS but whether that was the only one, i don't recall, but i'm pretty sure it wasn't, and whether that issue been addressed or not, i don't know - i couldn't find any information about the issue other than a mention of HTTPS By Default add-on not working with TC (or maybe just containers period)

another potential reason to use HTTPZ vs. HTTPS Everywhere if you're running old hardware is the memory footprint - apparently the HTTPS-E uses aprox. 20 mB (to store its lists i assume) - so i think it might be worth adding to ptio as an alternative (not replacement for https-e as i originally suggested) for the following reasons...

• it's an efficient, minimalist add-on
• doesn't require any user interaction
• automatic and temporary downgrade (with user permission) if https fails
• doesn't rely on human curated lists - it always attempts to upgrade http

[atomGit]

and yet another reason to list HTTPZ as an alternative is the year old CSP bug in Firefox that affects HTTPS Everywhere - see here: https://forum.privacytools.io/t/psa-warning-to-all-firefox-users-that-install-add-ons/803