> TCP/IP on a local network will make mobile devices think they are on a captive portal. No, that's the phone doing a HTTP call to a server on the internet to

> TCP/IP on a local network will make mobile devices think they are on a captive portal. No, that's the phone doing a HTTP call to a server on the internet to try and work out if it's a captive portal, all TCP/IP still functions perfectly fine within an internal network with no WAN access. > DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers. The devices are on a local network, they're not making requests to things outside the network. Even if you do need outside access for resolution you can still happily use a DNS forwarder with your local DNS served up locally with any outside DNS (including DNSSEC) queries being forwarded where they need. > HTTP is not secure, so that is going the way of telnet. That's neither here nor there, it still works fine in the context of a local network. > HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer. A cert is as valid as my cert store thinks it is, again, still works on an internal network. > Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment. By "own internet island" you mean a local network? Sure it's more advanced than your nan's local network but it's still a local network in which the IP part of TCP/IP still works absolutely fine. Maybe you come from the land where your mongo instance needs a public IP, or that your lightbulbs can be used to pivot onto your home network. I don't. This is basic network design. Maybe the shitty software/hardware you're running shouldn't assume it will always be connected to the internet directly.