> Well, if that were a standardized way to establish trust, that necessarily would lead to vendors adopting it at the cost of suporting other kinds of setups?

So on one hand you believe that supporting one standard will necessarily come at the cost of supporting another (I don't), and you agree that what I suggested might cover 99%+ of the current user base, yet you favor a solution that depends on global addresses, something which definitely doesn't come close to 99% of potential users?

> Also, it is very problematic to overload not globally routable addresses (also often misleadingly called "private addresses") with security semantics.

Well, if you want to be really anal about it you could call them "addresses which fall into one of the address ranges allocated for private use", but you're just splitting hairs.

> While many home setups do have a sort-of security boundaries around RFC1918 subnets, there is absolutely no guarantee that that is the case.

There is no guarantee, but that's different from saying that it's inherently unsafe.

> Which is an argument for what exactly? Especially with regards to IPv6 and ULA?

It's a reflection on how the internet is built. It doesn't matter that in the ideal network, everything might have an address, when pretty much every device is behind some kind of NAT. IPv6? Come back when it's widely adopted.

> Why would that have stopped then? Again, in particular with regards to IPv6, which does not have the address scarcity that might have justified use of NAT and non-globally routed address space as a temporary workaround?

It stopped mattering because of address exhaustion and slow adoption of IPv6. Now, NAT is an integral part of the internet. I'm not trying to justify it or state this as a matter of preference—I'd definitely prefer having a ton of IPv6 addresses over the single IPv4 address I actually have—I'm just laying things out as they are, and how they are for the vast majority of consumers.

> ... just as not doing so does?

No. Flagging a website as "safe" when it can not be established that it is safe is at least as wrong as flagging it as "unsafe" when it can not be established as being unsafe. What I'm suggesting, not flagging it in any particular way at all, would be taking a neutral stance. IMO, the practice of calling HTTPS sites "secure" is itself potentially misleading to consumers. It is only secure in a very specific sense, likely not in the broader sense a layman would consider.

> Yeah, and how is your browser supposed to know that?

The question I stop at is "why is my browser supposed to know that?"

> What both?!

Both a way of verifying and distributing certificates network-wide in a LAN and for those certificates to be usable globally.

> The question is not whether it should, but whether it would. Suppose browsers were to implement a policy of "RFC1918 and ULA are considered safe unencrypted and -authenticated". What would vendors of devices do?

The premise of my suggestion is that the browsers won't back down from indiscriminately marking plain HTTP sites as insecure, hence "Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks."—so suppose they would support such a method. Would that be better or worse than current practice?

> Which probably means they won't bother providing an alternative mechanism. Which means (a) you can't use their devices in other setups and (b) their users are locked into such setups, which makes it impossible for, say, router vendors, to build more useful networking products that use the full potential of IP.

That's a load of conjecture. I'm not sure how to respond except with a bunch of other conjecture, so I'll refrain.