Firefox 143 for Android to Introduce Doh
Posted4 months agoActive3 months ago
blog.mozilla.orgTechstoryHigh profile
calmmixed
Debate
70/100
DNS-Over-HTTPSFirefoxAndroidPrivacy
Key topics
DNS-Over-HTTPS
Firefox
Android
Privacy
Firefox 143 for Android introduces DNS-over-HTTPS (DoH) to enhance user privacy, but the discussion reveals concerns about centralization, configuration, and the impact on custom DNS setups.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
23m
Peak period
97
0-12h
Avg / period
35.3
Comment distribution106 data points
Loading chart...
Based on 106 loaded comments
Key moments
- 01Story posted
Sep 17, 2025 at 9:14 AM EDT
4 months ago
Step 01 - 02First comment
Sep 17, 2025 at 9:37 AM EDT
23m after posting
Step 02 - 03Peak activity
97 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 25, 2025 at 8:15 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45275444Type: storyLast synced: 11/20/2025, 4:44:33 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
In the OS you need to trust (1) the OS vendor, (2) the client vendor & (3) any VPN app or HTTP intermediary that's integrated with OS network APIs.
In the client you need only to trust the client vendor.
Granted, the os would need to read your address space, not simply supply a recording DNS API, but still...
That alone makes a native browser implementation a better solution than the OS version.
[0]: https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the... is just one example I found on Google (in this case, using the C function getaddrinfo bypasses the tunnel entirely, which Chrome in particular uses for DNS queries - only android API calls respect the tunnel), but you hear about stuff like this every couple years; in that post they also link to a prior incident where connectivity checks and NTP updates were conveniently not using the VPN even when killswitches are active. Neither of these incidents have been fixed as of the time of writing (and Google explicitly doesn't consider conncheck/NTP calls occuring outside of the VPN tunnel to be a bug.)
Google has already shown to have a habit of not properly respecting privacy focused settings, and DoH is intended to be primarily privacy focused. (As it's used to prevent DNS tampering.)
You may or may not think this is a better design (I was one of the people responsible for Firefox doing things this way, so I do), but hopefully this explains the difference.
See: https://educatedguesswork.org/posts/dns-security-dox/ for more on the difference.
https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
But, and its a BIG BUT ....
Mullvad don't have the geo-coverage that Quad9 has. They are predominantly Northern Europe with very limited server coverage outside (6x Northern Europe, 2xUSA, 1xSingapore)
Which is fine if you spend most of your time in those three places.
But if you are a road-warrior or you live elsewhere, then Quad9 is the better choice as they have global coverage (200 locations, 90 countries).
Avoid Cloudflare. They log traffic. Sure for a short-time period ($n days) but Quad9 still has the better privacy policy.
Quad9 is also Swiss, not US, so they can't be compelled to do anything under PATRIOT or whatever.
That sounds like a GDPR violation if the logs include PII like IPs and if it's not opt-in. Is that really the case?
Cloudflare retain what they call "limited transaction and debug log data" for 25 hours.
Cloudflare state that IPs are truncated and the truncated IPs are deleted after 25 hours BUT for "randomly sampled network packets" they will retain the full IP for "network troubleshooting purposes".
Even so, as we know, a truncated IP can still be used to track and trace people ...
Compare and contrast to Quad9 who explicitly consider IP addresses as GDPR PII ("Quad9 regards Internet Protocol ("IP") addresses associated with its users to be Personally Identifiable Information ("PII")")
Quad9 states IPs are only ever in RAM "for the few microseconds to milliseconds necessary to service the user's query"
They also state "Quad9 does not collect or record IP addresses, nor does it collect or hold any proxy for or representation of IP addresses, nor does it collect or hold any other unique identifier of individuals in lieu of IP addresses."
Which is why I said Quad9 have a much better privacy policy.
[0] https://github.com/DNSCrypt/doh-server
Choose Quad9 if you want better security and Mullvad for it's adblocking options.
Hopefully we will see more regional DOH providers instead of centralized ones.
For example, the paper you cite here uses consistent hashing, where you hash the domain name and then divide by K where K is the number of the resolvers. However, consider the case where you have a conceptual site (e.g., Gmail) which actually loads resources from multiple FQDNS. For example, if you pull up the network console for a naive load of X, it loads resources from at least the following domains:
x.com, api.x.com, abs.twimg.com, pbs.twimg.com, video.twimg.com
All of these are relatively characteristic of X, but in a naive design they would often be loaded from multiple resolvers, with the result that you're actually sharing your browsing history with more resolvers than if you just had a single resolver. As is suggested by this list, you might be able to improve the situation somewhat by hashing on ETLD+1, but even here there are 2 ETLD+1s, which is not an uncommon scenario.
In general, for this strategy to work you need to hash not on the domain but rather on the conceptual site, but this information is not readily available to the browser.
For Waterfox for Android I exposed the setting by default and also added an addition DNS over Oblivious HTTP setting (DoOH) which uses Fastly as the relay (they host and control it, for privacy sanitisation) and Cloudflare as the resolver.
How is the latency?
> The first thing that we can say with confidence is that the additional encryption is marginal. We know this because we randomly selected 10,000 domains from the Tranco million dataset and measured both encryption of the A record with a different public key, as well as its decryption. The additional cost between a proxied DoH query/response and its ODoH counterpart is consistently less than 1ms at the 99th percentile.
[1]: https://blog.cloudflare.com/oblivious-dns/#what-about-perfor...
But more importantly, there's a system wide DoH setting in Android (or at least in GrapheneOS). I don't see why it would preferable to only configure DoH in the browser.
Am i the only one for which about:config does nothing on Firefox on Android ?
With the workaround in the sibling comment it can be accessed in both Firefox stable and Firefox Focus.
This allowed access from the standard settings page which you can see in this release, it’s the same setting just exposed instead of hidden.
I think Nimbus experiments also might have exposed the setting.
Whoever could see DNS traffic can still see the target you're connecting to...
A while back I wrote a quick proof-of-concept that parses packet data from sniffglue [2] and ran it on my very low powered router to log all source IP address + hostname headers. It didn't even use a measurable amount of CPU, and I didn't bother to implement it efficiently, either.
I think it's safe to assume that anyone in a position to MITM you, including your ISP, could easily be logging this traffic if they want to.
[1] https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt...
[2] https://github.com/kpcyrd/sniffglue
I'm running it on a device with a Qualcomm SM8635 Snapdragon 8s Gen 3 chipset, and it just crawls. The UI is very unresponsive, and page load times are terrible. It also has to reload the page if it was running in the background and you switch back to it.
For youtube background play Brave is much better.
Not saying your issues aren't real, but rather maybe there's another app or your manufacturer's flavor of Android that's causing the issue (like those aggressive background killers).
As for Edge, I used to be a big fan, but when they finally introduced history and tab syncing in 2021, it didn't have E2EE, and it still doesn't, which I find inexcusable. All the other major browser vendors offer it, even Google (though you have to opt in).
In https://support.mozilla.org/en-US/kb/canary-domain-use-appli... it says that the canary domain does not apply for users who have made the choice to turn on DoH by themselves.
I want to avoid running an sslproxy, and it seems an application level proxy on the firewalls is necessary.
The former approach is where we need to go with security IMO. If you don't have some auditability for why a computer on your network is making an outgoing connection (and ability to inspect/refuse it before it happens), then it should just be blocked. There's no reason for computers you own to reach out to random IPs you don't understand and can't inspect at your gateway. Most computing devices are preloaded with malware these days and need to be treated as untrustworthy by default.
[0] https://datatracker.ietf.org/doc/html/rfc8484
https://docs.google.com/spreadsheets/d/14IgSRVop4psUTgtLZlvY...
The request modification apis specifically.
And the defaults don't help: instead of your ISP seeing your queries, now it's Cloudflare, Google, or whichever big player your browser hardcodes. That's not decentralization, it's centralization under a shinier marketing story.
Encryption is good, censorship resistance is good, but the rollout conveniently shifts power away from users and toward a handful of global DNS silos. For technical folks, it feels less like progress and more like lock-in with extra steps.
Checkout RFC9463
One issue is, if you set DoH in the browser, you can not do DNS filtering in your dns server. It might be better to send DNS over VPN to your home lan, do the filtering there, and let your dns server send the dns over https.
Tailscale can send DNS from all devices to a server of your choice. From there, AdGaurd or Pihole will filter it and send it over https.
8 more comments available on Hacker News