Remove almost all online garbage using Dnsmasq(github.com) |
Remove almost all online garbage using Dnsmasq(github.com) |
General policies
* Should not break useful websites or apps
* Blocks tracking servers
* Blocks advertising servers
* Blocks analytics servers
* Blocks fake websites
* Blocks malware servers
* Blocks webminers
B. "tracking servers" "advertising servers" "analytics servers" "fake websites" "malware servers" "webminers"
If B is larger than A, then a whitelist for A is easier to maintain than a blocklist for B.
Following this logic is not for everybody, much depends on the user's particular web/app usage, but it has worked for me.
It forces an otherwise naive user like me to get to know the "useful websites" and "apps" better, e.g., to be aware of the domains and any third party resources they are using. Some are much more dynamic than others. Thus, some may require constant attention where others may only require an upfront, one-time sunk cost of my time.
Whereas reading through continually updated "blocklists", lists of servers that purportedly have nothing to offer me, is not something I want to be forced to spend time doing. How can we know that the people making the blocklists are not in collusion with the people behind the servers listed in B. At some point, we will be forced to look at what is listed in the blocklists.
I would rather spend that time on a personalised whitelist.
One personal annoyance is sites that use things like CloudFront and regularly change the host without assigning a vanity CNAME so you cannot simply whitelist *.cdn.example.com.
s/web/graphical &/
Additionally having DNS filtering in place will also prevent information leakage in case something goes wrong with one of your browser plugins.
Edit: So that's tunneled DNS.
You could also call it encrypted DNS, I suppose. But then, you could say something similar about VPNs, instead of calling them tunnels.
Hard-coded authenticated DNS would be hard too, but it's at least possible that you could see what resolver it's using.
The bit that will prevent me from pulling this trick in the future is the fact that it’s encrypted.
I was pretty shocked how many widgets and apps ignore the local DNS.
What the network approach doesn't help with is when the ads are served from the same domain as the content. An extension like uBlock Origin solves this problem because it filters the content within the browser.
So I think both approaches are necessary to filter out ads/trackers, and they also complement each other, one at the network level (dnsmasq or Pi-Hole) and the other at the browser/content level (uBlock Origin, PrivacyBadger).
Basically everything except computers. Smart TVs are another one.
- The failure mode is to block rather than allow. Even with a browser with adblocking addons, the addon could accidentally be disabled or uninstalled (by you, by a browser bug, by a browser feature, etc), so you'll start seeing ads. If the DNS server gets disabled you won't be able to resolve anything, let alone see ads.
(I used to do a home-made version of this, but resolving to a local gifserv so that I didn't have to see "page could not load" errors from ad spaces. But recently I got a pfsense router so I've switched to pfblockerng instead.)
Not sure what using dnsmasq would buy me over this setup.
Relevant: Windows will improve user privacy with DNS over HTTPS
Info from notracking: https://github.com/notracking/hosts-blocklists#dns-over-http... Info from Mozilla: https://support.mozilla.org/en-US/kb/configuring-networks-di...
Not sure if Microsoft will do something similar? Else there is still the option to set up your own (local) DOH server and let your router route all DOH traffic to your local DOH instance.
Since pihole and dnsmasq are already requiring disabling DoH, I see DoH as the dead of these kinds of adblock systems.
Why not unbound/bind/etc?
Most edge routers provided by ISP's are running dnsmasq on the underside.
I'd say opposite
It had less examples and docs compare to unbound. At least that was my reason to setup unbound 2 years ago
>Most edge routers provided by ISP's are running dnsmasq on the underside.
True and sad
dnsmasq simply isn’t very good.
Encryption is technically the hard wall of "technically infeasible" but I say authentication because at that point you start getting massive delays in things being operationally feasible since you're waiting for things to give up on resolving rather than signaling it's unresolvable/a bogus location.
If for example they will use the 1.1.1.1 DOH instance, you can simply redirect all localnet 1.1.1.1 (80/53) traffic to your own local (DOH)DNS(masq).
Besides that there must be a fallback option for network admins, since using dns filtering and localnet dns is very common in enterprise. Firefox implemented a canary domain, specifically designed for this purpose, see: https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
I log all attempts by devices on my network to port 53. Android apps, roku, google home devices, and various others are quite aggressive about going directly to various DNS servers if they don't get what they want from the local DNS server.
Using wireshark to track what's going on it's not unusual to see 7,000 DNS requests for a domain I'm blocking in just a few seconds. The android client for youtube seems to be particularly persistent.
You should not
Or you completely compromise DNS chain and as result you can not trust results of dns resolve
Quite a few apps and devices ignore the DNS recommendations provided by radvd (for ipv6) and dhcp (for IPv4).
That way I can block youtube, instagram, netflix, imgur, reddit, and similar services that my kids are addicted to if they are avoiding homework and the like.
How exactly does that "compromise DNS chain"? Unbound is DNSSEC aware, and talks to the same root servers that the ISP, google, opendns, or similar services would talk to.
Sadly DoH will make this much more difficult.
That will remove their most cherished authority, so clearly they would hate it and come up with endless fake excuses, but that's why open source matters.
If you want to trust it you have to be able to audit its workings. There is no magic sauce from a network layer that gets around this step and after this step nothing else is needed.
This is the fundamental problem; we provably cannot even know if the black box will even halt[1], we obviously cannot audit any it for behaviors far more complex than simply halting. Even worse, if the black box is equivalent to a Turing machine with more than ~8k states, it's behavior cannot be described in ZF set theory[2].
> There is no magic sauce from a network layer
As long as the black box is Turing complete, any noisy channel[3] to the network it can influence can be used as a foundation for reliable digital channel. The solution is to limit the black box to such that it is not Turing complete. The decision problems about its behavior must be decidable.
A good example of a limited design is the original World Wide Web. HTML with 3270-style forms (or an updated version that is better looking with modernized form tags) was decidable, with the undecidable complexity sandboxed on the server. The instructions to the client (HTML) and the communications with the server (links/URLs, POSTed form field) are understandable by both humans and machines.
Today's web requires trusting a new set of undecidable software on each page load. We're supposed to trust 3rd parties even though trust is not transitive. We're supposed to accept the risk of running 3rd party software even though risk is transitive. Now these problems are leaking into other areas like DNS, and the Users lose yet another battle in the War On General Purpose Computing[4][5].
[1] https://en.wikipedia.org/wiki/Halting_problem
[2] https://www.scottaaronson.com/blog/?p=2725
[3] https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem
It's open middleware, just like the glibc resolver. For example, it's entirely possible to force applications to use the glibc resolver, just dont let them open sockets to anything but 127.0.0.1:53. They wouldnt be able to use http/https either in that case, but that's the point.
If you are thinking about side-channels like HTTP over DNS(S), then fine, but the middleware can see the traffic because that's it's job. If the app starts making encrypted requests atleast you would know, and since it's open source the user can fix it and tell everyone the application is using a side-channel to subvert the user.
_But that missed the point._ The app wouldnt have DNS code in it. It would only be able to ask to map a name to a record. And even then, that misses the point too. In the end it wants to fetch a URL, and what I am talking about does that. Firefox parses a GET it was handed, and if it wants to make additional GET/POST's, then hand them over. No DNS or networking code needed in the browser. Linking to a SSL lib would be a bug.
Reaching into an arb open source app and getting ahold of it's SSL machinery to MITM it is always a moving target (aka deliberate problem), and that's an anti-user feature.
Common middleware that handels the comms (SSL etc) (os or application level) levels the playing field. The recent DoH changes would have been up to the user, because that code isnt in the browser any more. Users are leveraged by the browser vendors, "want the latest version?" "hey I see you are using a 0-day browser?" and forced to swallow or fork. I realize users can disable DoH, but again, that's the point. It's a moving target. They can just keep "fixing" the defaults.
Same thing with Chrome's recent changes regarding the DOM blocking API. If Chrome was forced to deal with asing for URL's instead of fetching them directly, it wouldnt matter. The blockers would operate in the middleware.
As I mentioned in my original comment, the point is to axe the networking code from the applications, and force them to make requests a layer up. This is not like forcing them thorugh a SOCKS proxy. It's deduplicating the code, and making the parts seperable. The monolithic nature of browsers isn't some accident.
So say you give the black box in your sandbox a socket (from the above definition). Say it is a news app. This news app loads headlines and articles. How does your sandbox know if the headline/article text contains some form of encoding? How does it know the timing of requests isn't leaking information out about your viewing patterns?
I spend quite a bit of time railing on JS. Executing arb code is fundamentally a bad idea (Halting Problem).
https://hn.algolia.com/?dateRange=all&query=jakeogh%20%22dis...
> This page will only work with JavaScript enabled
Really!? Why the hell would you link to that?