[part 2] > On the other end of the extreme, someone could be tapping a cable far away from my computer and figure out what connections I make regardless of enc

[part 2] > On the other end of the extreme, someone could be tapping a cable far away from my computer and figure out what connections I make regardless of encrypted data. Somewhere in between the two extremes, close to the likely, the party that I establish a secure connection too could be sharing our communication with other parties. Which is in no way in conflict with saying "this is insecure". That is in conflict with saying "this is secure", because that implies "... against this specific set of threats", which is not understood by the average user. So, yes, I agree, browsers should generally avoid telling users that something "is secure", but it is perfectly fine to say "this is insecure". > We've already established that the browser can't know it, so is the browser a fundamentally flawed concept? No, it's just a subjective entity as all entities in the world are, and so it has to determine risks based on incomplete information, as all entities in the world have to. Also, it's not strictly true that it cannot know that, but it cannot know that without you telling it. It might well be possible to have an option where you could tell your browser "this set of addresses is safe to talk to unencrypted and unauthenticated". > Yes? The only part you seem to disagree with is the possibility of having a router in a local network (and yes, local networks exist) facilitate and streamline the exchange. No, I disagree primarily with overloading the semantics of "private addresses", and with mechanisms that only allow communication in a local network. "private addresses" is neither reliably indicative of nor a required property of "within the same local network". But also, a mechanism that does not depend on being on the same local network for pairing would be preferable. > So again, a perfect application for a router? The router is in a perfect position to verify that I am on its network. OK ... how? > Yes, as evident from the absolute lack of overlapping authentication and encryption standards... ... implemented in the same product, where one of them would always have been enough to meet the requirements of 99% of potential users, and the others would have taken considerably more effort to implement?