Loading…
HTTPS Everywhere + uBlock #1408
4 participants
It could be based on the order in which the extensions were installed, but then the odd thing (from a Chrome perspective) is that the most recently installed extension wouldn't be the one to intercept requests first.
Anyway, the only case in which the order should matter is if your rulesets target just the HTTPS or just the plain HTTP version of any given ad or tracker; most rules that use domain names start with || and those target all subdomains, both HTTP and HTTPS, and in that case, the requests end up cancelled regardless of whether uBlock intercepts them before or after HTTPS Everywhere gets to see them (most other rules just target path components, and those work on all domains they appear on, whether HTTP or HTTPS).
I just played a little bit with the Firefox network analyzer tools. The requests that HTTPS-E lists as redirected HTTP->HTTPS are not made. Seems like HTTPS-E redirects them and then uBlock blocks them after (but before any actual request is done), but HTTPS-E still lists them as "secured by HTTPS-E" (with a green entry in the drop down menu of HTTPS-E).
This issue still exists after upgrading to 0.9.4 directly from github (before I used the 0.9.1 version from Mozilla). HTTPS-E was installed in both cases before uBlock (but I can not remember if it was installed before or after AdBlock Edge over a year back).
So, this boils down to a cosmetic issue, which is most likely even on HTTPS-E side and not on uBlock side.
Being a substitute for AdBlock and RequestPolicy (and more) maybe you should also implement automatic rule-based HTTPS redirecting with HTTPS-Everywhere ruleset syntax, then we'd have an all-in-one solution. ;)
Is there any way to "fix" this from uBlock's site? Sure, it's mainly a cosmetic issue so nothing really important, but I would still find it nice to only see connections in the HTTPSEverywhere menu that are actually made.
Besides, I wonder if it wouldn't save some additional resources if HE wouldn't have to check for and convert connections that won't be made anyway.
Extensions cannot change the order in which the browser lets them intercept network requests.
Scenario: FF 37 with uBlock 0.9.1.0 and HTTPS Everywhere 5.0.4, switched from AdBlock Edge.
I'm not sure if this behaviour is intended, but AdBlock Edge blocked content before HTTPS Everywhere did it's magic. I was very confused after switching from AdBlock Edge to uBlock with the same rulesets to suddenly see HTTPS Everywhere doing a lot more redirects. So, I'm confused now if the connection to unwanted ad sites actually was established or not: HTTPS-E says yes (because it lists it green as secured to HTTPS), uBlock says no (it lists the HTTP version red with a minus in the logs).
So, was the HTTP version blocked, but the HTTPS version established? What happened here? Who to trust?