While it is true, I should think that it should be better to be up to the end user to decide what they want, and that it should not assume that everyone else knows better instead. If the user writes "http" then it is http, if the user writes "https" then it is https, etc. (What it should do if the suer does not specify the scheme is a different question, and different users may have different preferences (which should probably be configurable). My preference is that it would treat the URL as relative instead of absolute in that case, but that is probably minority.)

Most users have no idea what any of this means. Even I often don't know what one is best. I want to use https:// if it's available, and http:// otherwise. Should every time I want to click a link, I instead right click to copy the link location, then paste it into the URL bar and modify it to https:// to try that, and then if it fails to load, change it back to http:// ? That's a massive amount of work. I want it to just work without all that hassle and having to keep a info in my mind of which websites support https:// and which don't.

>If the user writes "http" then it is http, if the user writes "https" then it is https

Should we also block the website from doing a redirect to https:// ? HSTS is basically just a redirect cache.

> Most users have no idea what any of this means.

OK, but users who do know what it means should be allowed to configure it differently. The computer software should be designed for advanced users, who do know what it means (and includes documentation in case you do not know).

> I want to use https:// if it's available, and http:// otherwise. Should every time I want to click a link, I instead right click to copy the link location, then paste it into the URL bar and modify it to https:// to try that, and then if it fails to load, change it back to http:// ?

No; it should be configurable to do it automatically how you want to do.

> I want it to just work without all that hassle and having to keep a info in my mind of which websites support https:// and which don't.

There are also other ways to do that even without HSTS, though. Still, it should be configurable by the end user.

> Should we also block the website from doing a redirect to https:// ?

No, that it isn't up to the client side to block. (I think that most web sites should not automatically redirect in this way, but that is not related to the client software.)

> HSTS is basically just a redirect cache.

Then it is deficient since it is not the only kind of redirect. Furthermore, it is bad because it does so without the user's specifying if they want this cache or if the user wishes to override it for any reason, making some things difficult to do. It should not try to think they know better than the end user what the end user is wanting to do.

>OK, but users who do know what it means should be allowed to configure it differently.

Yeah, I agree. In order to avoid bloat, it might be best to offload this to extensions.

>No; it should be configurable to do it automatically how you want to do.

I agree, but I think complex configuration should be offloaded to extensions. By default it should do what the website owner wants (HSTS).

>Then it is deficient since it is not the only kind of redirect.

Other kinds of redirects aren't relevant for security, so they don't need as the degree of cache guarantees that HSTS provides.

>Furthermore, it is bad because it does so without the user's specifying if they want this cache

Stuff should be secure by default. We don't want security to be opt in.

>or if the user wishes to override it for any reason, making some things difficult to do.

I agree there should be overrides.

>It should not try to think they know better than the end user what the end user is wanting to do.

Sometimes the end user actually doesn't know what the end user is trying to do and gets phished. I agree there should be overrides though, but they need to be carefully designed so that attackers can't abuse them.

> In order to avoid bloat, it might be best to offload this to extensions.

While it is a good idea to avoid bloat, there are some problems with this:

- The web browser is too bloated already, and its features are not offloaded to extensions. (If they were (offloaded to extensions which are then included with the browser by default), then it would be easier to customize those features, and the extension mechanism would be sufficient to add new HTML commands, file formats, protocols, character encodings, etc too.)

- WebExtensions is incapable of many things. (I don't know if it can affect the location bar behaviour, but XPCOM is capable and is what I have done on my computer. One thing that WebExtensions definitely does not do is to load native .so files natively. Of course native code should not be available in the public extension catalog, but would be useful for advanced users who can add it by themself.)

> I agree, but I think complex configuration should be offloaded to extensions. By default it should do what the website owner wants (HSTS).

I think it should be unnecessary. If you have a header overriding option, then it makes many other settings unnecessary, and the user can then make settings for cookies, languages, HSTS, referer, JavaScripts and other features (using CSP), user agent override, and many other things, without needing separate settings for those things.

> I agree there should be overrides.

Yes, but unfortunately the HSTS specification, and web browser authors, does not want.

> Sometimes the end user actually doesn't know what the end user is trying to do and gets phished. I agree there should be overrides though, but they need to be carefully designed so that attackers can't abuse them.

I think differently. It might need to be a separate program, which is the "advanced users web browser", you can override and set everything. I don't like this modern software that is not designed for advanced users. Software should be designed for advanced users.

One idea is that a better implementation can be a web browser engine which consists of a lot of independent components (HTTP, HTML, CSS, PNG, JavaScript, WebAssembly, key/mouse events, ARIA, etc; available as separate .so files perhaps (with their own source code repositories)) that can then be tied together by a C code (the main program); a programmer can modify or rewrite some or all parts of this code, to make a customized web browser with your own functions changed.

>and its features are not offloaded to extensions.

I think commonly used features should be built in, and rarely used features or features where people can't agree on how the UI should look, should be in extensions. I think HSTS customization would be a rarely used feature, so should be in an extension.

I think I agree that most of what you're saying would be ideal. I'm not sure how much of it is doable though when you consider programmer time constraints.

> I think commonly used features should be built in, and rarely used features or features where people can't agree on how the UI should look, should be in extensions.

Unfortunately doing it makes it difficult to work. Also, the extension mechanism is deficient.

If multiple kinds of web browsers are made, so that it is not a monopoly, then they do not all have to be made the same way.

They shouldn't all be Chromium or whatever; they can be something else. If you have separate components, then you can more easily replace them or tie them together differently, without having to use inefficient extensions, modify the source code (which is large and might take a long time and be complicated), waste disk space and memory on unused features, etc.

Yeah. Although, as you mention modifying the source might take a long time, similarly implementing multiple browsers would take a long time. I don't know what the solution is.

> Yeah. Although, as you mention modifying the source might take a long time, similarly implementing multiple browsers would take a long time. I don't know what the solution is.

That is why I think that separating out the components might make it easier for other people to independently build multiple browsers.

> Most users have no idea what any of this means.

That's a bad reason to do things. Users will learn what is made important to them. Red website for http, green website for https. Nice big lettering to translate to the non technical user 'Protected' mode versus 'Unsafe' mode.

Yeah for power users show all the nitty gritties, but this isn't about being technical or not - it's not being communicated properly and instead its just hidden.

When your spouse doesn't communicate well with you, starts having an affair, and then hides it, _thats NOT a good thing_.

All this talk of pasting urls...thats not how users use the web. Nobody is keeping in mind which websites support https or not. They do care what happens when they browse.