AdGuardSDNSFilter VS counter.dev

https://github.com/AdguardTeam/AdGuardSDNSFilter

If you don't trust their DNS servers for whatever reason, you can simply add these entries to your hosts file to replicate their functionality locally.

Opened pull request: https://github.com/AdguardTeam/AdGuardSDNSFilter/pull/1418

You don't really need AdGuard DNS in this setting, the filter it use is already included in the DNS blocking filter if you enable it, which you should, since this way DNS requests are filtered immediately instead of having to go all the way to the AdGuard DNS server every single time. Feel free to combine it with other DNS servers if you want, eg, maybe you find one that is faster/blocks malware better, etc. The requests then will only resolve if the adblocking filter doesn't block it and the DNS server also approve it.

Posted and issue to fix it: https://github.com/AdguardTeam/AdGuardSDNSFilter/issues/1260

linkt-transport.top · Issue #1185 · AdguardTeam/AdGuardSDNSFilter (github.com)

Technically, not all rules in EasyList are included in AdGuard DNS, because some of the rules are URL patterns that can't be supported by DNS-based filtering.

Adguard DNS Filter? You mean this one? https://github.com/AdguardTeam/AdGuardSDNSFilter There's a link there in project description.

If you're asking what DNS filters I use on AGH, then it's a mixture of adblocking, security, and specific purpose. I'm using the standard AdGuard filter plus:

> Rather than what looks to be an unproven pet project of some developer. If nobody is paying for it, there are no guarantees of uptime or support.

It's pay what you want. The project is running for three years already, let's see how things go with time.

Apologies for the long downtime. The issue is being resolved, see here for updates:

- https://github.com/ihucos/counter.dev/issues/124

- counter.dev -> Something that I need but it has a lack of accuracy and very tiny functionality.

> Right, and being sessionStorage it's cleared on browser close, and the next time I visit I will be counted as another daily unique visitor right?

No! There are a few rudimentary mechanisms on top of each other if one of them fails as you described. The /track endpoint sets up http caching. So if sessionStorage fails, you still have that. Then there is also inspecting document.referrer. If it is the page you are already on, then it's definitely not a unique visit.

> (or why not just a cookie)

Because cookies are considered "bad". But technically basically just saving a boolean value on the cookie would not be worse from a privacy perspective than using sessionStorage for a boolean value.

> I personally would rather have the pages I visit use a self-hosted solution gather everything I do, instead of a third-party getting little data from many sites I use. If this script is used across many sites it can be checked server-side against my IP to get my usage. I can never verify what logs they keep and for how long.

That is a general problem with externally hosted services. You can audit the source code (https://github.com/ihucos/counter.dev) but there is not way to verify that my deployment is as stated. I heard a podcast once that web hosters could guarantee that a deployment is in a specific way and contains a specific code base revision. But such solutions unfortunately do not exist. If you really want to be sure self hosting is the way to go (but somewhat cumbersome)

I think you can go with counter.dev

I am providing a free and open source web analytics service: https://github.com/ihucos/counter.dev / counter.dev

From their Github. ​