From 2860ce612b26e10195e7f0480ee57d01afd66b34 Mon Sep 17 00:00:00 2001
From: Daniel Micay
The recommended approach to system-wide ad-blocking is setting up domain-based
+ ad-blocking as part of DNS resolution. You can do this by
+ choosing a Private DNS (DNS-over-TLS) server with support
+ for blocking ad domains. As an example, AdGuard DNS can be used by setting
+ dns.adguard.com
as the Private DNS domain.
Content filtering apps are fully compatible with GrapheneOS, but they have serious + drawbacks and are not recommended. These apps use the VPN service feature to route + traffic through themselves to perform filtering. This approach is inherently + incompatible with encryption from the client to the server, which the AdGuard app + works around by supporting optional + HTTPS interception by + having the user trust a local certificate authority, which is a security risk and + weakens HTTPS security even if their implementation is flawless (which they openly + acknowledge in their documentation, although it understates the risks). It also can't + intercept connections using certificate pinning, with the exception of browsers which + go out of the way to allow overriding pinning with locally added certificate + authorities. Many of these apps only provide domain-based filtering, unlike the deeper + filtering by AdGuard, but they're still impacted by encryption due to Private DNS + (DNS-over-TLS). If they don't provide their own remote DNS servers, the apps require + disabling Private DNS. They could provide their own DNS-over-TLS resolver to avoid + losing the feature, but few of the developers care enough to do that. Using the VPN + service to provide something other than a VPN also means that these apps need to + provide an actual VPN implementation or a way to forward to apps providing one, and + very few have bothered to consider this let alone implementing it. NetGuard is an one + example implementing SOCKS5 forwarding, which can be used to forward to apps like + Orbot (Tor).
+