While it is possible this is a slippery slope that leads to the case you are referring to. It's still not clear if it will ever reach that state.
Blocking of Win32 apps/apps not from the Windows Store already exists today [0], although who knows how long until it is not "voluntary" anymore. The text in the message from the linked article kind of gives one of the future "reasons" Microsoft will probably use in the future for this kind of shit away ("Limiting installations to apps from the Store helps to keep your PC safe and reliable").
This development presents a VERY slippery slope.
[0]: https://arstechnica.com/information-technology/2017/02/windo...
Edit: You could argue that the ChromeOS platform is an example of a completed locked ecosystem. I've never really considered Chromebooks to be a PCs, but I'm sure under some context they meet the classifications of a PC.
I also severely doubt they'll attempt to prevent installation of application binaries from sources other than the Windows store. If anyone were going to be dumb enough to attempt such a move, it'd have been Apple, years before now, and they never even came close. Microsoft isn't run by morons, either.
And they could trivially forbid loading file:// URLs or disable features for those since few people use those anyway, that way you would lose persistence and would be dependent on something to even host your software.
I'd argue it works better than sockets, especially for gaming, since there's no need to mess around with NAT.
With real sockets you can just send a multicast message to find all devices on the local network and talk to them directly.
There is no third party in charge. There is just a requirement to use some party anywhere.
And they still have to agree on the same server, that provides a certain lock-in or inertia. Ultimately it means you have less control over your network connections than with real sockets.
And for the purpose of discussion this about the freedom of running software on your computer and webcontent not being equivalent in that regard. With webrtc signalling servers you're just kicking the ball down the road because then you need to be able to run a server with access to real sockets on some other machine, just to use those poor imitations of sockets.
Set up your hosts file or edit the js to point at a local server.
Of course, if you're in China you'd get in trouble making connections to an outside STUN server but if you're in China you're in trouble making connections to the outside anyways, and the STUN connection is probably the least of your worries.
> just to use those poor imitations of sockets
... that work across NATs without issues, as opposed to real sockets...
---
In any case, WebRTC doesn't strictly speaking need discovery servers at all. See http://blog.printf.net/articles/2013/05/17/webrtc-without-a-... It still uses STUN for public-ip discovery, but comments indicate that can be bypassed by just configuring the connection to use a local IP for STUN. Unsurprisingly, not many people seem to actually care about that.
You say that as if stun didn't exist in the udp/tcp realm. bittorrent clients in fact engage in serverless stun by using mutually reachable peers. real sockets are strictly more powerful than webrtc, period. Also, that argument is becoming more and more obsolete as ipv6 adoption increases.
And again, this is not about utility, it's about control and freedom.
> In any case, WebRTC doesn't strictly speaking need discovery servers at all.
Even if you don't use a server you need to exchange one-time connection tokens out of band. You can't re-establish connections at a later point either. And it does not support multicast either. So no, you can't just have devices talk to each other.
Anyway, you're not even responding to my central argument. Web content is not a substitute for unfettered native access because you need native access to things (e.g. running a server) to even be able to run web content.
> "no one can run nginx without authorization".
Your freedom does not end when the last person on earth who could run nginx cannot do so any longer. It ceases when you can't do it on the device you own on a whim of a 3rd party.
* Photoshop * Illustrator * Premier * Avid * Office * Visual Studio
etc. etc. Legacy applications are a huge reason for people to use Windows. Blocking themselves off from that rich ecosystem of applications is basically begging people to use a Chromebook.