AdGuardHome VS easylist

Also AdGuardhome will use optimistic caching, which is great.

https://github.com/AdguardTeam/AdGuardHome/discussions/4002#...

The main repo is GPLv3: https://github.com/AdguardTeam/AdGuardHome

They already have many other commercials products and I guess also the default filter rules are very good because of their experience in the domain.

But I think you can use it completely without the AdGuard servers and use other filter list sources.

How it compares to let's say AdGuard Home? Seems similar https://github.com/AdguardTeam/AdGuardHome

Adguardhome - Clients identification issue

You can check this documentation if you want to investigate further: https://github.com/AdguardTeam/AdGuardHome/wiki/Hosts-Blocklists

I'm using adguardhome v0.107.42 openwrt snapshot on linksys wrt1900ac v2, but when using DoH it won't resolve upstream DNS, but DoT is works perfectly OK, I've already set allow_unencrypted_doh to true in config .yaml file as per instruction here

AdGuard Home?

https://github.com/AdguardTeam/AdGuardHome

Regarding open source, AdGuard DNS actually is:

How does this compare to adguard home [ https://github.com/AdguardTeam/AdguardHome ] ??

Have you looked at AdGuard Home - Configuring clients?

import { ScreenshotOptions } from "./schema"; import puppeteer, { Page } from "puppeteer"; import { PuppeteerBlocker } from "@cliqz/adblocker-puppeteer"; import fetch from "cross-fetch"; let blocker: PuppeteerBlocker | null = null; async function blockCookieBanners(page: Page) { if (!blocker) { blocker = await PuppeteerBlocker.fromLists(fetch, [ // the list of the cookie banners to block from the https://easylist.to/ website "https://secure.fanboy.co.nz/fanboy-cookiemonster.txt", ]); } await blocker.enableBlockingInPage(page); } export async function render( options: ScreenshotOptions ): Promise<{ url: string }> { const browser = await puppeteer.launch(); const page = await browser.newPage(); if (options.block_cookie_canners) { await blockCookieBanners(page); } await page.setViewport({ width: options.viewport_width, height: options.viewport_height, deviceScaleFactor: options.device_scale_factor, }); await page.goto(options.url); const encodedScreenshot = await page.screenshot({ type: "jpeg", encoding: "base64", fullPage: options.full_page, }); await browser.close(); return { url: `data:image/jpeg;base64,${encodedScreenshot}` }; }

uBlock Origin has a few lists for cookie banners that I always keep on [0][1]

[0] https://github.com/easylist/easylist/tree/master/easylist_co...

[1] https://github.com/AdguardTeam/AdguardFilters/tree/master/An...

I think this is now fixed (or worked around) by https://github.com/easylist/easylist/issues/17937 ?

You mean the VG Wort METIS tracking in order to participate in the German royalty scheme? From a publisher perspective that tracking is necessary, but from a user perspective it's just another example of third party tracking. Thus, it is part of some filterlists that uBlock Origin users can subscribe to, for example the EasyPrivacy list. Talking to the filterlist authors is very unlikely to resolve this: after all, it is tracking, regardless of intention.

Fixed in EasyList: https://github.com/easylist/easylist/commit/859abc79711aa69441e809a394677f6392b8c59a

If I have noticed a new ad, to which list should I report a filter issue? Should I report the new advertisement to the issue tracker at uBlockOrigin/uAssets, or should it be reported to EasyList instead?