Rebuttal: Endpoints that talk to services on public networks are part of the public network, not a private network — even if they are behind middleboxes such as firewalls. Endpoints on the public network should be distinguishable one from another.
Applications should be able to count on an addressing system that distinguishes endpoints, not just networks. That assumption was baked into the design of TCP/IP, allowing the creation of a wide variety of network applications. Many early applications don't work under NAT without application-specific workarounds. NAT has badly encumbered the design of modern applications, to the point where people now assume that there is a hard distinction between "servers" (machines that have public addresses) and "user machines" (that don't).
In the TCP/IP design, hosts are distinguished by addresses, and services on those hosts are distinguished by port numbers. In the NAT non-design, the hosts on a "private" (not really private, that is, air-gapped) network cannot be distinguished by addresses. As such, applications protocols cannot make intelligent use of addresses, and developers of applications intended to run on hosts located in homes and offices are hampered in what they can offer, by having to work around NAT all the time.
NAT conflates several issues; notably security policy and addressing. The ostensible security benefit (disallowing inbound probing of "private" endpoints) can actually be had without losing the benefits of a public addressing: it's called a default-deny firewall, it's existed since before NAT, and you can have it even with public addresses behind it. (Though neither NAT nor default-deny firewalls provide general security, especially in the browser era, where endpoints run nearly-arbitrary software they've fetched off the net.)
NAT requires protocol-specific workarounds — either in the middlebox itself, such as port forwarding, or in the application, such as STUN. These deeply encumber application design, in ways that encourage centralization and discourage distributed protocols.
Endpoints that talk to services on public networks are part of the public network, not a private network — even if they are behind middleboxes such as firewalls.
Only if these endpoints service incoming public requests. If my machine, for example, functions solely as an SSH terminal to tunnel into a public server (and has no open ports), I don't see how it can be counted as a "part of the public network" in any meaningful sense.
Endpoints on the public network should be distinguishable one from another.
Yes, but not on internal LANs which is ...
At LW London last week, someone mentioned the possibility of a Google Glass app doing face recognition on people. If you've met someone before, it tells you their name, how you know them, etc. Someone else mentioned that this could reduce the social capital of people who are already good at this.
A third person said that something similar happened when Facebook started telling everyone when everyone else's birthday was. Previously he got points by making an effort to remember, but those points are no longer available.
Are there other social skills that technology has made obsolete? And the reverse question that it only just occured to me to ask, are there social skills that are only useful because of technology?
I'm not really sure what sorts of things I'm looking for here. "Ability to ask for directions" seems like one example, but it feels kind of noncentral to me, I don't know why. But I'm mostly just curious.