Improving Opportunistic Encryption (OE) Topic is solved

[sinfulosd]

I was not aware of this feature being on the browser, until I've been tempering with the preferences and I noticed what that was and I decided to use and do some tests with it. The feature looks great. However, I've been testing this feature to see if it would replace the usage of me having HTTPS add-on installed on the browser and I'm not confident to admit that it can replace it, due to the browser feature missing some key components, in comparison to the HTTPS add-ons

• If the server doesn't support Upgrade Insecure Requests, then the browser option will do nothing whatsoever. HTTPS Inquirer, somehow, still detects HTTPs availability on non-UIR supporting servers (I think it's because it additionally has the "Fall back to GET" option of HTTPs detection, if the UIR header is not sent back by the server).

• The browser option will always send an unencrypted request first, which could be attacked by a MitM. A saved HTTPS Always rule will skip the unencrypted request and prevent this type of attack.

Those 2 key components that exists on the HTTPS-enforcing addons and do not exist on the native OE feature are very important to have. Why not implement these 2 QoL changes into the browser feature?

[Moonchild]

If the server doesn't support Upgrade Insecure Requests, then the browser option will do nothing whatsoever.

That is exactly as-intended. If the server does not support/respond to an OE request then the browser should not decide on its own to change the requested protocol. It's called "opportunistic" for a reason.

The browser option will always send an unencrypted request first, which could be attacked by a MitM.

This is what HSTS is for.

HTTPS-enforcing addons and do not exist on the native OE feature are very important to have.

Then by all means, if this is very important to have for you, use the HTTPS-enforcing (note the difference between "enforcing" and "opportunistic") add-ons. It's why Pale Moon is extensible.

Why not implement these 2 QoL changes into the browser feature?

A bit more in-depth in response to this: they are not quality-of-life changes. What you're asking for is bypassing the mechanisms for opportunistic encryption and forcing the protocol to https whenever the server seems to support it (which would require guesswork on the browser's side) and not the server indicating that "Yes, we are OK with this, you can use https if you want for the same request". the same kind of thing goes for HSTS: unless the server indicates they promise a long-term commitment to HTTPS through HSTS headers, you shouldn't lock out http as a protocol for it.
Also, keep in mind that ultimately, these technologies are transitional: they were designed to be used when a website is transitioning from http to https, and explicitly excludes situations where a website provides http and https separately on purpose. These technologies are based on client-server agreement, not enforcement.