uBlock Origin CNAME uncloaking now supports filtering by IP address

Original Article ↗ Hacker News Discussion ↗

CNAME cloaking & uBlock Origin’s new capability

  • CNAME cloaking lets third‑party ad/analytics services appear as first‑party subdomains (e.g., media.site.com CNAME → tracker’s infrastructure), bypassing simple domain-based filters and some third‑party cookie protections.
  • uBlock Origin on Firefox has long supported “CNAME uncloaking.” The discussed commit refactors that logic and adds the ability to filter by resolved IP address and to apply rules earlier in the request lifecycle.
  • This helps block cloaked requests even when subdomains are constantly changing, though it’s imperfect when multiple IPs exist for one domain.

Privacy, tracking, and security implications

  • Even with third‑party cookies restricted, tracking continues via first‑party integration, APIs between sites and ad networks, and browser fingerprinting (window size, fonts, GPU, IP, headers, etc.).
  • Some argue CNAME tricks reduce cross‑site correlation (since cookies are per site); others note vendors can still correlate via server‑side data sharing.
  • Security concern: if third‑party ad servers sit on subdomains that share cookies, they might impersonate logged‑in users. Proposed mitigations mentioned include careful cookie scoping, public suffix configurations, and DNS CAA, though there is disagreement on how effective measures like HSTS are in this context.

Ad ecosystem, liability, and user sentiment

  • Many see the move to cloaked first‑party subdomains as a reversal from earlier reluctance to mix core content and ads, driven by the need to evade blockers.
  • Comments highlight rampant ad fraud, scammy content, and the cost pressures that favor automated ad networks over in‑house sales and review.
  • Some argue sites hosting malicious ads should face legal liability, especially when ads are effectively first‑party.
  • General sentiment is strongly negative toward surveillance advertising; some see limited, contextual ads as acceptable, others reject advertising entirely.

Manifest V3, Chrome, and browser choices

  • Manifest V3 deprecates key blocking APIs (notably webRequest.onBeforeRequest) in Chrome, which users say cripples powerful, heuristic-based blockers like uBO.
  • There is debate whether MV3 “by definition” forbids such features: one side notes the spec explicitly restricts blocking webRequest; another points out Firefox implements MV3 while preserving blocking APIs, so the limitation is really in Google’s implementation.
  • Chrome is phasing out Manifest V2; Canary builds already warn or disable uBO. Some expect eventual full removal; others note Google has backtracked on controversial changes before, but respondents think ad revenue interests make reversal unlikely.
  • Many plan or have already switched to Firefox (full uBO support) or Brave (built‑in native adblocker, partial MV2 support “as long as feasible”), while recognizing Brave’s dependence on the Chromium codebase.

Defensive browsing practices

  • Several commenters report heavy lockdown setups: disabling first‑party cookies by default, allowing only HTML/CSS/images, blocking all JavaScript and whitelisting per‑site, and combining browser extensions with DNS‑level filters (e.g., Pi‑hole‑style).
  • Others note usability issues: some sites and CAPTCHAs break under Firefox or strict privacy settings, though spoofing a Chrome user‑agent often helps.