add FAQ entry on ad-blocking

1 files changed, 33 insertions, 0 deletions

diff --git a/static/faq.html b/static/faq.html
index fed69b96..951898a0 100644
--- a/static/faq.html
+++ b/static/faq.html
@@ -78,6 +78,7 @@
                         <li><a href="#network-monitoring">Can apps monitor network connections or
                         statistics?</a></li>
                         <li><a href="#firewall">Does GrapheneOS provide a firewall?</a></li>
+                        <li><a href="#ad-blocking">How can I set up system-wide ad-blocking?</a></li>
                     </ul>
                 </li>
                 <li>
@@ -504,6 +505,38 @@
             enforcing the INTERNET permission, such as DownloadManager. Direct access is denied
             by blocking low-level network socket access.</p>
 
+            <h3 id="ad-blocking">
+                <a href="ad-blocking">How can I set up system-wide ad-blocking?</a>
+            </h3>
+
+            <p>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
+            <a href="#custom-dns">choosing a Private DNS (DNS-over-TLS) server</a> with support
+            for blocking ad domains. As an example, AdGuard DNS can be used by setting
+            <code>dns.adguard.com</code> as the Private DNS domain.</p>
+
+            <p>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
+            <a href="https://kb.adguard.com/en/general/https-filtering">HTTPS interception</a> 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).</p>
+
             <h2 id="day-to-day-use">
                 <a href="#day-to-day-use">Day to day use</a>
             </h2>