Log to console when redirecting

[gbnrileuhg1]

Today I had two issues where it was hard to find the culprit: First, manually navigating to a site not available over HTTPS where several attempts of re-adjusting the URL didn't work (because I was too fast and the failing load wasn't finished), and second, a new tab of a page that redirects HTTPS to HTTP opened by an external application that's supposed to be intercepted by another addon (resulting in an infinite redirection error, solvable by hitting "retry", but not by adjusting the URL).

In both cases I ended up looking at the browser console for hints. Especially in the first case this was misleading, as there actually was an entry by one of the other HTTPS-enforcing addons I'm using. More specifically by one of the two which are new to my setup as replacement of a non-WebExtension addon. The one where I knew there needs to be an exception for this domain. So, of course I forgot about other addons. In the second case I'm still not totally sure it's HBD's issue (I don't mind hitting "retry" in that case anyway).

With a log entry, it would've been easier to figure out where this redirect is coming from. Though honestly, in the second case I might've not stumbled upon the solution/workaround if I had known where the redirect happens, but that was just luck.

TLDR: Currently the addon's actions are invisible in the console, I'm suggesting to add a log message when a redirect happens.

[Rob--W]

where several attempts of re-adjusting the URL didn't work (because I was too fast and the failing load wasn't finished),

So you tried to load http://example.com (the extension changed to https://example.com) and then before any reply came back you tried to navigate to http://example.com again? I'm not 100% sure about what happens if you try to repeat the navigation, but it is very well possible that the HBD does not change the redirect, because of this logic: https://github.com/Rob--W/https-by-default/blob/24316a0b5d1c91672114d9df834f9f4752f17945/firefox/background.js#L131-L134

If that logic didn't prevent the redirect, I guess that I could counter the issue by adding a new rule that allows a http:-navigation to go through if it's a repeated attempt to navigate. But that's gets more complicated.

With a log entry, it would've been easier to figure out where this redirect is coming from.

Logging redirects to the console can be a potential privacy leak, unfortunately.

PS. The current WebExtension has worse functionality than the original HBD add-on due to the limitations of the WebExtensions API. If you were used to the previous behavior, you could restore it by using the instructions at https://github.com/Rob--W/enablelegacy-firefox-addons to re-enable legacy add-ons. If you use these instructions, be aware that legacy add-ons are not really supported by Firefox, so complex add-ons will likely not work in the long run (e.g. legacy NoScript still worked reasonably in Firefox 57 and 58, but in Firefox 59 it caused errors and performance issues). The risk is smaller with the original HBD add-on (source code) because it is a relatively simple add-on, and I used defensive programming.

[gbnrileuhg1]

So you tried to load http://example.com (the extension changed to https://example.com) and then before any reply came back you tried to navigate to http://example.com again?

Exactly. It's one of those pages that time out on HTTPS, so it's quite easy to be that fast :-) If you want to try it: db.geopp.de

Logging redirects to the console can be a potential privacy leak, unfortunately.

I'm curious now: Can websites read the console (which imo would be really unexpected and thereby an privacy issue of it's own) and figuring out installed addons is what you mean, or is there something else I'm missing? If it's just that: What about optional logging?

original HBD

Indeed, only recently did I finally update due to the need of replacing simple (features of) addons like NoScript or "Disable Ctrl-Q" (if only Mozilla would fix that bug on Linux...) :-) But I prefer to update early rather than to rely on legacy interfaces longer than unavoidable. Thanks for the hint anyway, I might use it for dcqs :-)

[Rob--W]

Exactly. It's one of those pages that time out on HTTPS, so it's quite easy to be that fast :-) If you want to try it: db.geopp.de

Thanks. I can confirm the bug.

I'm curious now: Can websites read the console (which imo would be really unexpected and thereby an privacy issue of it's own)

Of course not. I mean more for a physically-local attacker. The risk is extremely small (and when the browser data is cleared via Ctrl-Shift-Del, the console seems to be cleared too), so perhaps I am too cautious? I'll add an option to enable logging.

[Rob--W]

I uploaded version 0.4.4 to AMO. Please install the update and confirm whether the issue has been resolved.

[gbnrileuhg1]

Yes, logging works fine.

In case you're interested in fixing the redirection loop bug (though I personally prefer having to confirm such a redirect, but a different error message would be better), maybe I should mention an example domain: stimme.de. I'm closing this issue ticket, as that's off-topic in this ticket :-)

[Rob--W]

@gbnrileuhg1 Thanks for another test case. I've published a new version that ignores redirects.