Even without using authoritative DNS, if we only have a blocklist of IP addresses and some application-level firewall solution, we can examine outgoing HTTP headers in a client-side proxy and filter accordingly.
I also do not use a popular browser that runs Javascript to send and retrieve to and from the internet. That is the root cause of most users problems. This is the most effective solution, bar none. The third parties users want to avoid are almost almost always depending on Javascript to accomplish their goals.
Connecting a powerful interpreter with potentially full control over the users computer to the open internet. Then believing this can be safe.
The user is granting use of this interpreter to third parties. In this thread we can see how users struggle to know which third parties can be trusted. All for the sake of keeping that interpreter open to "good" third parties to access at will over the internet. (Why is a good question.)
Early web browsers called on other, separate programs to do specific jobs outside of rendering HTML. Taking a cue from that history, I use simpler, limited programs with no built-in interpreter to do two specific jobs: sending and retrieving.
Third parties can return code in response to requests for content, but I am under no obligation to run the code, let alone run it from a popular browser with a powerful interpreter that is connected to the internet.
Cannot speak for others, but this approach has worked well for me as the www worsens.
Even without using authoritative DNS, if we only have a blocklist of IP addresses and some application-level firewall solution, we can examine outgoing HTTP headers in a client-side proxy and filter accordingly.
I also do not use a popular browser that runs Javascript to send and retrieve to and from the internet. That is the root cause of most users problems. This is the most effective solution, bar none. The third parties users want to avoid are almost almost always depending on Javascript to accomplish their goals.
Connecting a powerful interpreter with potentially full control over the users computer to the open internet. Then believing this can be safe.
The user is granting use of this interpreter to third parties. In this thread we can see how users struggle to know which third parties can be trusted. All for the sake of keeping that interpreter open to "good" third parties to access at will over the internet. (Why is a good question.)
Early web browsers called on other, separate programs to do specific jobs outside of rendering HTML. Taking a cue from that history, I use simpler, limited programs with no built-in interpreter to do two specific jobs: sending and retrieving.
Third parties can return code in response to requests for content, but I am under no obligation to run the code, let alone run it from a popular browser with a powerful interpreter that is connected to the internet.
Cannot speak for others, but this approach has worked well for me as the www worsens.