[CGamesPlay]

I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self-signed certificates much less common, I doubt there's going to be energy put into improving the experience with them.

[tialaramex]

As well as the affirmatively "insecure" marking in the URL bar for unencrypted HTTP, it's not a Secure Context (except localhost) and so modern browsers don't offer any new features for this case.

If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist.

The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.

[momentoftop]

An MITM attack on an HTTPS connection looks exactly like an untrusted HTTPS connection, and the main purpose of HTTPS is to prevent a MITM. The browser should rightly scream louder here than it does for an unsecure HTTP connection.