[part 1]
> Not necessarily, but the designer of a standard could take both use cases into account.
Which doesn't help if it's a separate mechanism. If 1% of the work gets you to the goal in 99% of the cases, that's what vendors will do. Whether that fulfills the requirements of some standard or not does not matter.
> What, more precisely?
I am not making any suggestions as to the solution.
> Of course taking into consideration that 100% of users might not even have an internet connection.
So, if the device is one that does not inherently need global internet connectivity to be useful, then, yeah, things should work without global internet connectivity.
> One thing I'd like is for devices to a their key signature printed on a sticker. Then I can verify the signature, log in and generate a new key and password, generate a certificate that I can install myself or sign up with a service like Let's Encrypt.
Well, a fixed key is a problem, but other than that, yeah, an out-of-band path for key exchange sounds good.
> No, it's not misleading to say that they are allocated for private use. Your ISP drops connections to these addresses because they respect RFC1819 and don't route to the private address ranges. Even if they didn't, these address ranges are still allocated for private use, and your ISP is Wrong. They're only routable in the sense that IP would technically allow it, but the internet is not simply IP but a collection of standards and best practices.
OK, let's get this straight: What does "private" mean? It's a word with a whole lot of only partially overlapping definitions. For the purposes of this discussion, it is important to distinguish the aspect of "independent from official entities" from the aspect of "not revealed to the public", i.e. "providing privacy". RFC1918 addresses are only private in the former sense: You can allocate and use them without coordinating with RIRs or your ISP. However, they have absolutely nothing to do with the latter sense of providing privacy. That is why it is misleading to call them "private addresses": People understand that to mean that they are defined to provide some sort of secrecy or privacy or protection from the public or something along those lines, which they don't. It's not wrong, because there is a different meaning of "private" that fits exactly what RFC1918 are defined to be used for, but it is misleading because it leads people to assume that it encompasses more than that.
Also, whether ISPs do it or not doesn't really matter. What matters is that RFC1918 address space is in fact routed between networks that are not intended to trust each other. And that is perfectly within the uses intended in RFC1918. The RFC isn't concerned with home networks, really, but with "enterprises", and it defines "an enterprise" to be the scope of an RFC1918 allocation. Nowhere does it say that that implies any sort of trust or security relationship between machines within such an allocation. And also, in practice, it is common to link RFC1918 networks of different "enterprises" together, as a sort-of "meta-enterprise", where a trust relationship is even less likely.
The only thing that is "private" about RFC1918 addresses is that you can allocate them without coordination with IANA/RIRs/ISPs, and that you cannot expect an ISP to route them for you on the global internet. There is no privacy specified in the RFC.
> And sure, "private" has a very broad meaning. A browser could very well flag a certificate that was distributed from a private address as such and let the user decide whether they trust that source.
How does it matter for this whether the address is "private" (i.e., allocated without coordination with IANA/RIRs/ISPs)?
> Sure. But again, "in practice means when you build an IPv6 network", i.e. not a typical consumer, for how long more?
Erm, most IPv6 use is by consumers, with ~ 20% adoption based on google users?! Not sure whether that's quite "typical" yet, but certainly not unusual either. Most user devices support IPv6, and increasingly, ISPs are rolling out IPv6 to their customers with new subscriptions, which tends to come with new routers, which means that at that point their network is using IPv6 for all services that support it.
> Well, it involves IPv6, we can start there. We're talking about a new security policy that a major browser seems to want to implement shortly, definitely much more shortly than full IPv6 rollout.
Yes, and that is the only way to do it. If you wait until after full IPv6 rollout, you will have to work around assumptions that device vendors by then will have made based on the browser's behaviour, which means it only gets harder to implement. If you want to have any hope of success, you have to act now, when your actions can shape what device vendors will do.
> This is a very loaded question, given that we still disagree on whether a solution that works well both for globally routable and NATed devices is possible.
You have so far failed to even show a solution that works better for NATed devices than non-NATed ones.
> I never said that no one uses IPv6, so I agree that you don't follow.
Replace "noone" with "essentially noone" if you want to get my point.
> Let's say that I see your ladder. It's broken, so I tell you that it's unsafe. Unreasonable assumption? You take it down and bring another ladder. I don't see it, but I tell you it's unsafe. You see it and can clearly say that it isn't. Is it unsafe? Is it reasonable for me to tell you that it is unsafe?
Unsafety is not a(n objective) property of the ladder, it's a (subjective) state of your knowledge. The ladder will only either fail or not (that is an objective fact about the ladder). Even a ladder with partially broken steps might still hold up, and a ladder that is all new and shiny can still have some manufacturing defect that causes it to fail on first use. The former is good to use, the latter is not. But that is a useless concept if your goal is to minimize harm because you only know that after the fact. So, what we use instead is a concept of "unsafety". Statements about unsafety are an expression of our knowledge about something. So, the ladder with broken steps is considered unsafe, because based on what we generally know about the statistical properties of ladders with broken steps, they are known to have an increased failure rate. But then, you might apply load tests to that ladder and establish that it does carry the loads required reliably if you avoid the obviously broken steps, in which case it can be considered not unsafe. Mind you, nothing has changed about the ladder, only our knowledge about it has changed. Similarly for the new and shiny ladder, those are generally considered not unsafe because of what we statistically know about new and shiny ladders, and maybe about how ladders are tested after manufacturing. But then, you could test that as well, and maybe find that it breaks apart under light load, at which point you would change to considering it unsafe. Again, nothing has changed about the ladder, it's all about the knowledge you have about it. And the tests I suggested are not the end of that process of discovering the unsafety of a thing. You might still do other tests yet and come to yet another conclusion (like, I dunno, the testing conditions were unnecessarily harsh, and under more realistic usage conditions the opposite conclusion is appropriate).
Now, not knowing anything about the ladder is just another state of knowledge. And if your goal is to minimize harm, then the default is not to assume safety. Again, that is in no way a statement about the ladder. That does not mean the ladder won't hold up. That only means that the ladder is not known (to you!) to hold up. It is always and exclusively a statement about your knowledge about the ladder.
This is not about answering the question "will the ladder fail?", this is about answering the question "is it known to the best of our understanding that the ladder will not fail under some generally expected load conditions?". If the answer to that is "no", then that is reason to be cautious, and that is why the browser warns you/is going to warn you.
You can of course argue that your goal is not to minimize harm, in which case the default assumption does not apply ... but then the whole discussion is pointless, as you are then essentially just saying "if you don't care about minimizing harm, there is no problem with trusting unencrypted connections (of some sort or another)". True, but not my goal, and obviously also not the goal of those people implementing the change.
> Maybe that's actually the better option. But no, "security unknown" in that sense is not equivalent to insecure. As an extreme, I could create a network with an Ethernet cable between two off-grid devices that I control in a faraday cage.
Yes, you could. But the browser doesn't know that. Therefore, its subjective determination is "this is not known to me to protect your private data", and that is what it is telling you. If you know better, that's fine, but the browser doesn't, so it warns you. If you don't know better, you better should listen to what your browser is telling you if your goal is to minimize harm. If you do know better, why do you care that your browser warns you based on its incomplete knowledge about the world?