3 ms·
You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them. As for the DHCP part, if you're on a public netwo
by the8472 8y ago
You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them.
As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver.
OS resolver -> a single thing you need to secure
every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic
- Spivak 8y agoBrowsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP. I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.
- the8472 8y agoI don't think this is the proper approach. Once it's in browsers it will also be in electron applications. And those may update less frequently. Now you have balkanized implementations of custom DNS stub resolvers using different remote endpoints. That makes security updates more difficult, network issues more difficult to debug and so on. Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.