They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure...) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked/typed as http, they warn about downloads over http, and they're continuing to ratchet up such measures over time.

▲

foobiekr 2 days ago | parent | next [-]

If browser vendors really cared, they would disable javascript on non-https sites.

	▲	GoblinSlayer a day ago \| parent [-]
		https://googleprojectzero.blogspot.com/2025/03/blasting-past...

▲

fc417fc802 2 days ago | parent | prev [-]

> they increasingly attempt HTTPS to a site first even if linked/typed as http

And can generally be configured by the user not to downgrade to http without an explicit prompt.

Honestly I disagree with the refusal to support various APIs over http. Making the (configurable last I checked) prompt mandatory per browser session would have sufficed to push all mainstream sites to strictly https.

▲

JoshTriplett 2 days ago | parent [-]

> And can generally be configured by the user not to downgrade to http without an explicit prompt.

Absolutely, and this works quite well on the current web.

> Honestly I disagree with the refusal to support various APIs over http.

There are multiple good reasons to do so. Part of it is pushing people to HTTPS; part of it is the observation that if you allow an API over HTTP, you're allowing that API to any attacker.

▲

fc417fc802 2 days ago | parent [-]

> if you allow an API over HTTP, you're allowing that API to any attacker.

In the scenario I described you're doing that only after the user has explicitly opted in on a case by case basis, and you're forcing a per-session nag on them in order to coerce mainstream website operators to adopt the secure default.

At that point it's functionally slightly more obtuse than adding an exception for a certificate (because those are persistent). Rejecting the latter on the basis of security is adopting a position that no amount of user discretion is acceptable. At least personally I'm comfortable disagreeing with that.

More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot. As an example, I expect a stern warning if I attempt to uninstall my kernel but I also expect the software on my device to do exactly what I tell it to 100% of the time regardless of what the developers might have thought was best for me.

▲

JoshTriplett 2 days ago | parent [-]

> More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot.

I agree with this. But also, there is a strong degree to which users will go track down ways (or follow random instructions) to shoot themselves in the foot if some site they care about says "do this so we can function!". I do think, in cases where there's value in collectively pushing for better defaults, it's sometimes OK for the "I can always make my device do exactly what I tell it to do" escape hatch to be "download the source and change it yourself". Not every escape hatch gets a setting, because not every escape hatch is supported.

	▲	fc417fc802 2 days ago \| parent [-]
		> escape hatch to be "download the source and change it yourself" In theory I agree. In practice building a modern browser is neither easy nor is it feasible to do so on an average computer. Given that a nag message would suffice to coerce all mainstream operators (thus accomplishing the goals I've seen stated) I'm left unconvinced. That said, I'm not particularly bothered since the trivial workaround is a self signed certificate and the user adding an exception. It's admittedly a case of principle rather than practice.