Well as hnyman already stated, adblock is network wide DNS-level protection against all sorts of malicious (sub-)domains ... for all connected devices, not just browsers. Still it's possible to combine that with different browser plugins as you like.
Than there is nothing to whitelist!
Usually ads are not delivered by the primary content provider (like spiegel), but rather from bigger, third party ad platforms from google, amazon, facebook ... you name it. You need to unblock those domains to see ads again ...
Do you use a Turris Omnia device? Saw your unusual user name few minutes ago in turris forum.
That's not possible with adblock, cause it uses the dns backend only (which returns a 'NXDOMAIN' for ad related domains) and doesn't use any kind of http redirection.
Hello and thanks for this great package & making it play well with dnsmasq,unbound and others. Could you tell me if the default uclient-fetch is sufficient for downloading https lists? Okay I have libustream-ssl installed.
Also as a suggestion, can we, in the future maybe, install pixelserv-tls and then adblock can generate the config to redirect to the pixelserv IP instead of 0.0.0.0?
@dibdot I'm sorry that I mentioned pixelserv in particular. It could be for any webserver like an instance of lighttpd or nginx without ssl of course. AFAIK DNS server config points to IP only, not port.
ancient adblock 1.x works with IP redirects to web server instances - this has been replaced a better/faster dns centered NXDOMAIN approach. No complex and error prone firewall rules & sinkhole web server configurations, no performance degradations with https adserver farms etc. ... currently I don't see any reason why we should switch back to the old approach.
@dibdot Dirk, I was just recently trying your previously posted Stylish suggestion for Firefox on the latest stable version of Firefox to replace the browser error message on https blockages. Stylish kept showing that the created rule was working on every page, however, the browser error on https blockages still was visible. Is this Stylish code snippet still working on your end? Or has the code snippet possibly changed with recent versions of Firefox or recent versions of your adblock package? Thank you.
Do you know if anyone has figured out a method yet for replacing similar browser error for https blockage on Chromium/Chrome?
With more and more ad/tracker servers going https, it seems to be driving the rest of my family crazy with the large/bulky browser errors on https blockages. It does not concern me too much because I run Adguard for Windows on my main machine which essentially replaces/cleans up any cosmetic artifacts so I don't notice it so much. But for the iPhones, iPads on the network as well as a few other Windows machines with Chromium, it is an issue that stands out more these days. Please let me know if you have any ideas or solutions. Cheers!
Hi Dave,
sorry no solutions from my side ... since firefox switched to WebExtensions-API it's no longer possible to hide those dns error messages with stylish. I use only noscript as additional browser plugin to stop offending javascript code ... maybe others come up with a better idea.
Hi, I'm the author of pixelserv-tls. Thanks to @neko for mentioning this tool.
I think "fake" and "hijack" are too strong words to describe pixelserv-tls. It's doing no more than you're faking and hijacking DNS records to begin with regardless redirecting to an IP or NXDOMAIN. In pixelserv-tls, all privacy is in control of users' hands. In fact, it also allows users to inspect what websites are sending them about you over SSL connection.
On performance, my quick and dirty benchmark on pixelserv-tls vs NXDOMAIN shows a tie.
This is not a strictly a legal or technical question, but rather an opinion question - "is it acceptable?" From my point of view it's not. A root ca cert in your system allows the controller of that cert to potentially impersonate and intercept any of your SSL/TLS traffic via MitM techniques. I don't want to get into self signed certs and forcing users to load CA's on all their devices. Plus that is just a bit too far into a Man In The Middle scenario and I don't want that kind of access to peoples devices. I'm very big on user privacy and no one should have unverified CA level access to clients.
DNS is unencrypted and provides no security guarantees. TLS on the other hand does.
If DNSSEC was all of a sudden enabled everywhere, a different approach than NXDOMAIN would be needed but that time has not (and probably never will) come.
What you're not seeing is DNS sinkholing, aka returning NXDOMAIN for a legit webserver operating under the law, is a MitM. The certificate technique is a more elaborate MitM to pull off than a compromised DNS forwarder/resolver, which is a one-step process. These are not opinion, but facts.
"is it acceptable" is easy to answer. There are two senses in your question. Let me clarify.
Sense 1: Ad networks/trackers collect consumers/end-users privacy data and send the data over HTTPS to their servers. Is it acceptable? To me, it's definitely not.
Sense 2: A consumer/end-user uses a tool such as pixelserv-tls to inspect such transmission within his own devices and check what privacy data the ad networks/trackers are retrieving from him. It's perfectly acceptable. That's what I meant in the sentence you quoted.
The FUD here is in fact a technical question. Note that neither pixelserv-tls nor its integrator will ship a root CA certificate. Each end-user has to generate his own root CA certificate. So each root CA certificate is unique and solely owned by the end user. He then installs the root CA in his and/or his family's devices for adblock. There is no MiTM attack here unless he wants to attack his family who trusts him in the first place to let him install the root CA.
pixelserv-tls also works without a root CA certificate. HTTPS requests will simply be rejected.
DNS-based adblock strategy is getting more popular, and easier to install. It works so much better than browser add-on. If its popularity gets to a tipping point, DNSSEC adoption may get a boost. I haven't looked into DNSSEC, so unsure if it can make DNS based adblock irrelevant. My guess is it can. Then it'll be a big win for ad networks and trackers.
I have good news for you (and maybe others). In firefox you can still clear those annoying dns related error messages from https sites. It's no longer permitted by internal plugins via webextensions api, but you can still provide a little external css file to nuke those error messages ...
/*
* edit this file and copy it as userContent.css to
* linux: /.mozilla/firefox/<profile dir>/chrome/
* windows: %APPDATA%\Mozilla\Firefox\Profiles\<profile dir>\chrome
*/
@-moz-document url-prefix('about:neterror?e=dnsNotFound') {
:root {
--in-content-page-background: none !important;
}
body {
display: none !important;
}
}
Maybe this works also in Chrome but I do not use this browser.
