There should definitely be a more convenient way to 'forget this site'. In Firefox it's hidden in right clicking on the site entry in History. For Chromium it seems to be a 7 step process unless invoking developer tools as History doesn't present a 1-click way to remove a whole site.

Edit: And for mobile even more obscure.

In a negotiation, the goal is to reach an accommodation suitable for both parties. If the web developer doesn't want to set up his server on port 80 to serve HTTP, that's his business. Your user agent is still working for you, when it negotiates with the server what protocols it will accept. (It also negotiates a content type for the response; and if all the server has is static HTML, it's not your user agent's fault if what you get is HTML, even if you really wanted some other format. Take it up with the web developer, if you want the data in some other format. The browser is just doing its best for you.)

Your argument makes sense in one narrow circumstance which is not the typical HSTS setup: if the server is serving the site with plain HTTP on port 80 (and not just a redirect to the HTTPS version of the page), and also has a HTTPS version with HSTS headers. (So that the first time you visit the HTTPS version, your browser will insist on taking you to that version every time.)

Don't forget what search engine is default, what sponsored stories are shown, turn those off, it's suggested stories next. Oh your bookmarks, why not share those with us, browser experiments, ... Thought that's enoigh? No, let's disable APIs that ad blockers use and replace them using BS excuses. Don't get me wrong, the companies developing the browsers spend money that they have to make somehow on the other end but at least there used to be usable community driven browsers..

Oh yeah, Google is really bothering me right now with that crap! I run adblock for an accessibility reason, not just for an I hate ads reason. Stop trying to ban me from the entire internet, and especially YOutube!

Out of curiosity, why do you want unencrypted HTTP when HTTPS is available?

For signed content where confidentiality is not important, an unencrypted HTTP connection is totally fine.

Some components of Public Key Infrastructure itself use unencrypted HTTP for this very reason. See Online Certificate Status Protocol (OCSP) - a method for distributing Certificate Revocation Lists.

Many Linux distributions operate package repositories in this manner. It allows caching of packages through a variety of methods.

Generally, CDNs can distribute signed HTTP content without requiring a customer to share a private key as would normally be required by HTTPS. So long as confidentiality is not a requirement.

The IETF, Google, and Cloudflare have been developing standards for it.

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-s...

https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

https://developer.chrome.com/blog/signed-exchanges

https://news.ycombinator.com/item?id=29281449

These examples are not in the browser context at all.

The package repo one is. You should be able to browse it over HTTP, just as they also used to be browsable via Internet Explorer's FTP mode.

Parent post didn't expliticly ask for browser context only.

Why? What benefit is there to browsing a package repo over plain http when https is available?

Mitm attacks seem incredibly dangerous in a package repo. Signing only gets you so far - and they probably don’t protect you from downgrade attacks.

Whether or not there is a benefit should be a judgement left up to the user.

There's no benefit to saving a file on a floppy disk, but if I tell my computer to copy a file to my floppy drive, I don't expect it to say "No, can't do that. You should be using a USB flash drive--they're better in all ways!"

I'm sure there's plenty of good reasons for wanting to use unencrypted HTTP, just like there's probably plenty of reasons to enjoy using floppy disks.

But I'm asking you: Why do you want to use unencrypted HTTP? Surely there must be some reason you want to do that, right? You (and others) clearly care a lot about this. I'm sure you're not an idiot. Help me understand your point of view here?

In this specific case, it's a crappy IoT device supporting only TLS 1.1. So when my browsers "helpfully" redirect me from the http:// interface to the https:// interface, they then "helpfully" refuse to work because TLS 1.1 is icky and end-of-life and browsers have decided that means "tell the user to fuck off."

At the end of the day, I worked around all of this browser helpfulness by using Firefox and re-enabling TLS 1.1 in Firefox's settings. I never actually managed to force any browser to use http:// despite trying many proposed solutions in this thread and on the web.

But all that aside, it doesn't really matter why I want to use unencrypted HTTP. I am commanding my computer to do it, and I expect it to carry out my command. My computer is a tool. It should do what I want it to do, even if that might hurt me. If I type in sudo rm -rf /usr, I expect it to do what I tell it to do. Not ask "Why do you want to do that?"

honestly, i run into the same issue. my use case is mostly for older wifi capture portals which just dont work against https since they obviously cant mitm the user. my other use case is for development work when I want to capture the traffic with wireshark without setting up https stripping via pinned certificate myself.

why do you want to save a file unencrypted on your filesystem, when encryption is available?

You generally shouldn't. But data at rest is different from data in transit in that you are vulnerable to a MITM with data in transit. Who cares if you're saving an encrypted file or not, if you can't trust that it's the same file that you intended to access.

Because I still want access to my files if there is a catastrophic system failure?

Saving unencrypted data at rest is not possible anymore on macOS. Even though it may appear as unencrypted, it is always encrypted.

With all respect: because I want to, and I expect my computer to do what I command it to do, not second-guess me. I understand the use cases for HTTPS vs. HTTP, and in some cases I deliberately want HTTP. It is not my browser's job to wag its finger at me and "correct" me.

I'm really tired of using a computer and feeling like a passenger rather than the driver.

Then use Firefox. Firefox has an option for this:

https://superuser.com/questions/1721511/firefox-allow-http-u...

https://support.mozilla.org/en-US/kb/https-only-prefs#w_enab...

There’s plenty of reasons to be mad at big corporations. But for now at least, Firefox still supports your right to make bad life choices on the internet.

I worked on a project where the site uses HTTP. Initially I did a double take as using requires a login, thinking that's just wrong.

But after a bit of reflection I now think that in this specific case there's nothing bad about using http. Services are offered on a first come first serve basis to a large but closed group of valid users. Key is that there are a bunch of real world processes that follow the initial trigger with no practical way for any other party to benefit.

The site is extremely simple but blazingly fast.

Sorry, but why is http a benefit here? Http has lots of downsides - like the traffic can be snooped and edited. (It is edited by many ISPs for advertising. And in countries like Australia the ISPs are required by law to log all http requests.) And of course, you can’t use http2 without tls.

What is the benefit to turning https off?

> Case in point which I'm fighting with at this very minute: HTTP. I want to access a site over HTTP, not HTTPS.

I think there's a fix for this in firefox and its forks, browser.fixup.fallback-to-https or dom.security.https_first maybe... at least they used to allow you to disable that sort of thing.

Browsers need to be more eager to offer workarounds for things like... that dang snake oil TLS cert on the ISP's router setup in a weird way but in the 'reserved' private use address ranges.

NOT automatically, but with an accommodation that asks the user if they're _expecting_ to talk to a device such as a "Modem" or "ISP Router" when making that request, and offer to do what's necessary to connect.

While I find this mildly annoying at times, it's a good reminder that I can just hardcode the port if I want HTTP