blocklists VS easylist

It lets you run the "on-device" version of RethinkDNS+. It lets you set blocklists to help you block domains based on categories such as trackers & ads, cryptocurrencies, gambling, social media, adult, security etc with precurated list of blocklists (which are defined here). These are DNS-based blocklists, so as such, they're less powerful than anti-ad browsers like Brave, Vivaldi or browser-based plugins like uBlockOrigin, AdGuard.

There's an open issue to include it: github/serverless-dns/blocklists/issues/21 (the reason we haven't already is that it isn't clear if existing blocklists are insufficient compared to it).

Filter list: Rethink actually has had 1:1 filter support with NextDNS for a long time. It doesn't now since NextDNS has moved a lot of its filters away from the erstwhile open metadata repository. So, now we do our own lists: https://github.com/serverless-dns/blocklists

Commit: https://github.com/serverless-dns/blocklists/commit/ffc73385e166e4d74af20471abfda327f7d89bb8

The code that generates the blocklists is also open source.

We _do_ compile to reduce memory and cpu impact. RethinkDNS app can do 5M entries without breaking a sweat. You don't see us ask folks to not use larger lists because the implementation is such. The code which compresses these blocklists into a compact form for use on mobile devices is open source: github.com/serverless-dns/blocklists/

The repository that builds these (and other lists) for RethinkDNS (the resolver) is at https://github.com/serverless-dns/blocklists

[0] https://github.com/serverless-dns/blocklists

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?