Ungoogled-chromium: forcing https on localhost

[jacques-andre]

Describe the bug:

Whenever I try access my localhost development server it automatically redirects me to https:localhost rather than http:localhost I have also tried to use 127.0.0.1 but it also redirects me to https:127.0.0.1 rather than http:127.0.0.1.

I have tried all solutions on this stack overflow page although they are not working even after I clear my history.

I have tried to remove hsts entries for both localhost and 127.0.0.1 but it is not working.

This is extremely annoying and frustrating.

To Reproduce:

Have a development server running, I am using go-fiber and navigate to localhost. You will see that https is enforced rather than http

Expected behavior:

I want to be able to access my development server with the default being http rather than https

Screenshots:

https://imgur.com/InOPhw7

Environment:

• OS/Platform and version: MacOs Catalina 10.15.5
• ungoogled-chromium version: Version 84.0.4147.89 (Official Build) (64-bit)

[wchen342]

Should be the effect of this patch. If you know how to compile then remove the patch and recompile should solve the problem.

[Kein]

But why was this patch accepted without local exclusions in a first place?

[Eloston]

Well, that's because we didn't think of that use case in the original PR: #628.

We have a number of options, but each have their own problems:

1. Add an exclusion for localhost and all loopback addresses (including both IPv4 and IPv6). This would solve this issue specifically, but requires a developer to implement the change. Also, are there other situations where the protocol should be HTTP by default? What about private IP addresses?
2. Add a flag to toggle HTTPS by default. Probably similar amount of work as the first option, but can also address use cases where the user would want HTTP for most pages they visit. However, it doesn't satisfy users who want HTTP only for localhost.
3. Add some whitelist for domains and IP addresses that should be HTTP-only. This is possible via a freeform chrome://flags field value, but would require the most amount of work to implement.
4. Remove the patch entirely. Solves this issue, but it discards the efforts in #628.

If I had to choose, I'd go for Option 4 because I think the change for HTTPS by default is debatable at best, and it kinda conflicts with the objectives of ungoogled-chromium. EDIT: It's also the easiest option to implement. However, I have no strong preference for any option.

Thoughts?

[Kein]

Option 4 still has a workaround in a form of an extension and seems like the fastest to "implement" and solve the issue. The rest 3 require someone to work on and maintain a solution, so they seems less feasible in a long run.

[jacques-andre]

I think option 2 could work. I am already using https everywhere which doesn't force https on localhost so it's not like I would be missing out on having enforced https on sites other than localhost.

[jacques-andre]

any updates?

[Eloston]

Going to go with Option 4 until someone is interested in implementing the other options.

[tie]

@Eloston I’m interested in implementing this feature (again), as well as maintaining it as long as I’m mentioned somewhere in the discussion. I’ll look into implementing Option 2 or 3 this weekend.

FWIW I didn’t consider adding exclusions because I’m using self-signed certs generated with mkcert. Unless you are developing HTTP-only service, I strongly recommend using TLS connections since they are required for HTTP/2 and the upcoming HTTP/3 protocols. Those have some features (e.g. server push) you can’t test on good ol’ HTTP/1 over TCP.

[Kein]

3 seems most flexible if you want to put work into the feature but I think this goes too much into custom version of Chromium rather than just ungoogled, may be better leave to extensions like HTTPSE.
2 seems most simple and does not warrant too many changes.

[tie]

@Kein agreed. I’ll probably go with the second option then, and users who want more fine-grained control could use some third-party extension.

The issue with extensions like HTTPS Everywhere is that they don’t enable HTTPS, uh, everywhere. Usually it’s just a database of sites known to support HTTPS. Unlisted sites will still be accessed over an insecure connection by default. See also: HTTPS by default, similar patch for Omnibox.