> then monitoring and filtering will simply move to the endpoint

Good. That's where it belongs.

Except for endpoints where the user/owner has zero control.

Think your smart TV or Chromecast. Suddenly, they can do anything they want and you cannot stop them.

Devices you can't control are also a problem, but the endpoints are still the right places to implement filtering. You can't guarantee access to the data anyway, as they can always encrypt the content independently of TLS. Though they're more likely to pin their own certificates so they can't be MitM'd and simply refuse to operate in a network environment hostile to end-to-end encryption.

It's best to just wall untrusted devices off from the rest of the network so they can access the Internet as required to do their job but not interact with any of your other devices. Or alternatively, replace them with open-source devices you do control.

You're describing the world everyone wants. I would much rather OS's move to a system with a filtering API so I can get real errors like "connection not allowed by local security policy" instead of pretending like it works and then dropping packets or getting garbage responses from the appliance pretending to be my server.

Of course what we'll actually get is networks which require[0] your OS to attest that you are running in Secure Boot mode, so the network can ensure you are running an "approved" OS that prevents you from running VPNs or Tor or bittorrent or E2EE messengers...

[0] https://arstechnica.com/gaming/2021/09/riot-games-anti-cheat...

Ok, but filter on what criteria? If the connection is encrypted, how do you know what you should filter for?

the idea is that device traffic would be inspected by the OS via some subsystem that encrypts/decrypts application traffic. I'm talking out of my butt here, I am not an OS person or a dev.

I imagine instead of the web browser encrypting traffic before sending it on the wire, it would send it in the clear to a process on the OS ("Endec"? I'm trying to think of some word like codec or modem for encrypt/decrypt).

This process would be the hub for all endpoint encrypt-decrypt operations, and the place where all apps would trust to do the work. That way, inspection tools desired by the user (or in corp land, the admin) could hook in and do filtering.

Applications that don't want this, such as say, Signal or other hyper-privacy tools, could choose their own trust store and bypass it, if permitted by the OS admin. Otherwise, corps could block raw access to the NIC.

Hey, I hear you. That just means I'll have to get good at a different UI!