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.
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.