Single-handedly, Firefox (independently from how crappy it can be at times) is what is keeping me on Android. Its full extension support (i.e.: uBlock Origin support) is something that I can't really do without.
I do wonder if the crowd here knows of other good alternatives though - specifically, Android and/or iOS browsers with "full" uBlock Origin support (no uBlock origin lite, no other blocker, ...). I would love to be made aware of a few alternatives.
I am aware that there is a browser from Kagi that works on iOS (I think?) but it's still in beta and closed sourced so not ready for prime time on my device. I am also aware of some peers of Firefox like Waterfox.
Orion (by Kagi) with full ublock origin on iOS, atleast that was the case about 6 months ago that I am aware of on Apple’s ecosystem. I’ve long jumped to pihole/adguard home to block ads at the router level so I went back to stock safari after that and use Tailscale to retain the router blocking capabilities when I’m on cell service.
Not uBlock Origin but Brave's own blocker is written in Rust and it is much more battery efficient than Firefox+uBO. It is equally powerful too (you can also add custom lists). Firefox is both slow and eats a lot of battery.
Not sure why it took so long for Mozilla to expose the setting on Android, it's been a 'secret' setting for a long time. In fact, sometimes they let features ride the rails for a little bit too long IMO.
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.
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.
In theory could be as low as single digit ms overhead, assuming fastly and cloudflares PoPs being used are very close to each other. In reality it seems higher than that but I'm sure a lot of optimisations can be done.
This doesn't address why this needs to be built in to the browser when Android already does DoH by itself. I assume there's a reason, does anyone know what it is?
First not all Android versions do that, and not all vendors implement that. Not everyone is running the latest version and has a Google Pixel.
Second passing from the OS is less secure since there are a multitude of actors, Google, the device vendor, eventual VPN app, etc. that could get access to that queries (in fact apps to block ADS such as ADAway if you don't have root use VPN functionality to intercept DNS queries).
In the end if you want to be safe better not pass from the OS in the first place.
Query statistics is valuable data you can sell. Client DNS queries are in that regard similar to search queries and a default search engine setting, you can sell that to the highest bidder. So browser makers are incentivized to implement their own resolver with its own set of DNS servers instead of just the system ones. Either because they want to sell those statistics themselves. Or because they want to protect their users from the statistics collection of the underlying OS resolver or ISP resolver.
Yes, but for a browser to be overtly reporting visited sites somewhere is often seen as dubious. Doing it stealthily by sending DNS queries less so, at least for less knowledgeable observers.
Android does same-provider auto-upgrade if it determines that the recursive supports DoH (last I checked, if it's on Google's list). However, this means that unless you configure your own resolver, you're vulnerable to whoever controls the network substituting their own resolver. Firefox uses a set of vetted and pre-specified resolvers ("trusted recursive resolvers"), so is less vulnerable to this form of attack. I say "less vulnerable" because by default it will fall back to the system DNS on failure, but you can configure hard-fail.
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.
Yes, this.
AND while Firefox is providing you the control to choose when to enable or disable DoH, you don't get that control at OS-level, or even the visibility of what the OS is choosing on your behalf for each such query.
DoH in Firefox provides you the control to choose when to enable or disable and which DNS provider to choose, while Android does not provide any such choice or even make it known to the user when DoH is used or not.
In addition, Firefox only partners with DNS providers that have legally-binding agreements for strongest privacy guarantees - see https://wiki.mozilla.org/Security/doh-resolver-policy .
Android privacy tools are leaky (which is bad given it's privacy tooling, you don't want that to leak!) Their VPN tools on OS level are pretty notorious for not properly respecting kill switch settings[0].
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.)
Moreso giving a reason why you'd want an app to force DoH instead of trusting the OS to do it "correctly".
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're at the mercy of the hardware in all cases. You can't do anything without trusting some external party unless you make an apple pie from scratch, but reducing the number of parties needing trusting is usually a good security approach.
The hardware and OS in the case of DoH only gets the IP address for the connection. It's not horribly hard to figure out who owns that IP address, but it's definitely harder than just reading a domain name.
It's all about whether you trust the OS to not track you when doing DoH at that level. In both mobile browser ecosystems, I can see why users of a browser would prefer the independent browser to do the DoH themselves, rather than leave it to the OS.
does android not allow you to configure a custom DoH resolver? could Mozilla simply offer a public resolver, and encourage users to switch at the OS level (possibly including a first-launch dialog offering to set the configuration for you)?
You can set DoH in all major browsers in desktop. On iOS, you can use private relay.
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.
I have long been using my own recursive DNS server through Wireguard on my GrapheneOS device. I don't see how using DoH through one of the few well known centralized providers is better for privacy.
Any domain could instrument their DNS to associate your DNS servers with your sessions which is highly unique for you and possibly connects your otherwise distributed devices, it would be odd to me if none of them try to add this to a profile for you just with the expectation of clustering users by more typical configurations.
For those wanting a bit of privacy, you can run your own DOH server[0]. Be aware that the upstream requests can still be tracked, but additional safety steps can be taken such as hosting your own dns resolver (bind/powerdns), sending dns/doh queries over a vpn or tor connection, or spanning queries over multiple sources. Each has its own security and privacy implications, which is beyond the scope of this comment :)
Running your own DOH server comes with it's own set of risks, depending on your adversary. If you're the only person using a DOH server, then any requests that server make must belong to you. I'd argue that it's better to use a public server and hide in between the other users.
My main issue with DOH is failing to honor my internal DNS overrides to provide local addresses for services on my local network (externally the DNS entries point to the external address but internally the LAN address) It is so annoying fighting against DOH for this
Mullvad DoH is great, and things like ad-blocking seems to be more effective on Mullvad.
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.
>DNS query [...] in the clear. [...] (DoH) plugs this privacy leak [...] no one on the network, not your internet service provider [...] can eavesdrop on your browsing
Whoever could see DNS traffic can still see the target you're connecting to...
The promise is especially dangerous when a huge fraction of traffic doesn't use Encrypted Client Hello, [1] so the domain name is sent in the clear with the initial request to the server.
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.
But if that request is going to a large provider (GCP, AWS, CloudFlare), without the hostname, the request is going to be close to meaningless for the snoop.
This is correct. The right way to think of DoH is as part of a package of mechanisms (including ECH) that collectively are designed to close network-based leakage of browsing history. Used alone, it has some value but that value is limited.
Outside of IP-blocking known popular DoH hosts (e.g. https://github.com/jameshas/Public-DoH-Lists, and even then it's not the best since there's overlap with popular DNS hosts like Cloudflare), there's no good way to do it without break-and-inspect. That's because DoH is TLS traffic over 443, just with DNS inside instead of HTTP.
It should be possible to have a firewall rule to default deny outgoing connections and a DNS resolver that tells the firewall to allow a connection only after it has resolved it, but I don't know that there's anything off-the-shelf to do this yet. I imagine DoH providers are also either using known SNIs or ESNI, so you could block both of those.
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.
DoH is a technical win but a practical regression for anyone who actually runs their own DNS. With classic DNS, you could hand out your resolver via DHCP and transparently control local zones. With DoH, that's gone. You have to configure each client explicitly, because the traffic is wrapped in HTTPS and can't be intercepted.
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.
Firefox is a browser and so (1) people at Mozilla are comfortable with HTTP and (2) there has been a lot of investment in making the HTTP stack good. You will also notice that the lead author of DNS over HTTPS [0]
was a Mozilla employee.
Actually, DoH doesn't change the situation here one way or the other, it's just a transport. It's true, that Firefox's approach to DoH ("trusted recursive resolver") does. centralize traffic some, but DoH need not be deployed this way. For example, Chrome does what's called same provider auto upgrade, which doesn't change the resolver, but just tries to use DoH if available.
I'm not sure that this mechanism delivers the desired privacy benefit, and it's quite hard to make sure it does so.
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:
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.
I wonder why DOH is in the intro described as getting activated by region. Is DoH now active globally for every region, on any (desktop) platform (Mac/Windows) ?
It's been in the title of the RFC since 2018 and practically every mention I see is formulated as "DNS-over-HTTP (DOH)", so I imagine that's pretty rare.
Firefox for Android is some of the worst software I've ever used. A lot of extensions won't work in it, and even Edge Canary is far better with them. It is extremely slow, and the UI is horrible.
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.
Strange, I am running it on a Snapdragon 8 Gen 2 (Z Fold 5), and it's totally fine for me. (If anything, it's a little too good at staying in the background; if you have private tabs open it insists on persisting in memory.)
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).
I have a OnePlus 5T from 2017 with a Snapdragon 835 processor and find that Firefox works perfectly well on it. I also have a device with a Snapdragon 8cx Gen 3 processor and Windows 11 on ARM. Firefox runs smoothly on that too.
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.
Single-handedly, Firefox (independently from how crappy it can be at times) is what is keeping me on Android. Its full extension support (i.e.: uBlock Origin support) is something that I can't really do without. I do wonder if the crowd here knows of other good alternatives though - specifically, Android and/or iOS browsers with "full" uBlock Origin support (no uBlock origin lite, no other blocker, ...). I would love to be made aware of a few alternatives. I am aware that there is a browser from Kagi that works on iOS (I think?) but it's still in beta and closed sourced so not ready for prime time on my device. I am also aware of some peers of Firefox like Waterfox.
Orion (by Kagi) with full ublock origin on iOS, atleast that was the case about 6 months ago that I am aware of on Apple’s ecosystem. I’ve long jumped to pihole/adguard home to block ads at the router level so I went back to stock safari after that and use Tailscale to retain the router blocking capabilities when I’m on cell service.
This simply isn’t true, webkit cannot support ublock origin atm.
https://docs.google.com/spreadsheets/d/14IgSRVop4psUTgtLZlvY...
The request modification apis specifically.
I'm also using Orion on iOS, so far without any major issues. And adblocking still works great here.
Yes, this is still true. I use orion but I do find it to be a bit buggy.
Same. This was my reason for going back to safari (now w ublock lite) but with a dns adblocker like pihole/adguard home.
Not uBlock Origin but Brave's own blocker is written in Rust and it is much more battery efficient than Firefox+uBO. It is equally powerful too (you can also add custom lists). Firefox is both slow and eats a lot of battery.
Brave on iOS is fine. Works roughly like my old Android Firefox did.
Why not do dns adblocking so the device or browser does not matter
Because it's much less effective.
Kiwi browser allows the blocked chrome extensions such as ublock origin
Kiwi is no longer maintained
Samsung Browser do support few ad blocking extensions like ADB+ and AdGuard
Try lemur browser, it has extension support.
Try Vivaldi
Not sure why it took so long for Mozilla to expose the setting on Android, it's been a 'secret' setting for a long time. In fact, sometimes they let features ride the rails for a little bit too long IMO.
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.
It's been accessible via about:config, yes.
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.
> It's been accessible via about:config, yes.
Am i the only one for which about:config does nothing on Firefox on Android ?
try chrome://geckoview/content/config.xhtml
about:config is only available on Firefox Nightly because reasons.
With the workaround in the sibling comment it can be accessed in both Firefox stable and Firefox Focus.
Hey, just wanted to say thanks for your work on Waterfox!
> DoOH
How is the latency?
In theory could be as low as single digit ms overhead, assuming fastly and cloudflares PoPs being used are very close to each other. In reality it seems higher than that but I'm sure a lot of optimisations can be done.
This doesn't address why this needs to be built in to the browser when Android already does DoH by itself. I assume there's a reason, does anyone know what it is?
First not all Android versions do that, and not all vendors implement that. Not everyone is running the latest version and has a Google Pixel. Second passing from the OS is less secure since there are a multitude of actors, Google, the device vendor, eventual VPN app, etc. that could get access to that queries (in fact apps to block ADS such as ADAway if you don't have root use VPN functionality to intercept DNS queries). In the end if you want to be safe better not pass from the OS in the first place.
Query statistics is valuable data you can sell. Client DNS queries are in that regard similar to search queries and a default search engine setting, you can sell that to the highest bidder. So browser makers are incentivized to implement their own resolver with its own set of DNS servers instead of just the system ones. Either because they want to sell those statistics themselves. Or because they want to protect their users from the statistics collection of the underlying OS resolver or ISP resolver.
the browser, being the originator of these DNS queries, already knows what website you are visiting.
Yes, but for a browser to be overtly reporting visited sites somewhere is often seen as dubious. Doing it stealthily by sending DNS queries less so, at least for less knowledgeable observers.
Android does same-provider auto-upgrade if it determines that the recursive supports DoH (last I checked, if it's on Google's list). However, this means that unless you configure your own resolver, you're vulnerable to whoever controls the network substituting their own resolver. Firefox uses a set of vetted and pre-specified resolvers ("trusted recursive resolvers"), so is less vulnerable to this form of attack. I say "less vulnerable" because by default it will fall back to the system DNS on failure, but you can configure hard-fail.
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.
Yes, this. AND while Firefox is providing you the control to choose when to enable or disable DoH, you don't get that control at OS-level, or even the visibility of what the OS is choosing on your behalf for each such query.
DoH in Firefox provides you the control to choose when to enable or disable and which DNS provider to choose, while Android does not provide any such choice or even make it known to the user when DoH is used or not. In addition, Firefox only partners with DNS providers that have legally-binding agreements for strongest privacy guarantees - see https://wiki.mozilla.org/Security/doh-resolver-policy .
Android privacy tools are leaky (which is bad given it's privacy tooling, you don't want that to leak!) Their VPN tools on OS level are pretty notorious for not properly respecting kill switch settings[0].
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.)
What does your post have to do with DoH though?
Moreso giving a reason why you'd want an app to force DoH instead of trusting the OS to do it "correctly".
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.)
AFAIK Android does not do DoH but DoT - at least you can only set a DoT endpoint in the "private DNS" settings.
I thought Android only supported DNS over TLS, so at least this opens up options for people.
Privacy.
Why is DoH in the browser more private than DoH in the OS?
Because there are fewer actors to trust.
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.
Surely you're at the mercy of the hardware vendor and os in either case?
Granted, the os would need to read your address space, not simply supply a recording DNS API, but still...
You're at the mercy of the hardware in all cases. You can't do anything without trusting some external party unless you make an apple pie from scratch, but reducing the number of parties needing trusting is usually a good security approach.
The hardware and OS in the case of DoH only gets the IP address for the connection. It's not horribly hard to figure out who owns that IP address, but it's definitely harder than just reading a domain name.
It's all about whether you trust the OS to not track you when doing DoH at that level. In both mobile browser ecosystems, I can see why users of a browser would prefer the independent browser to do the DoH themselves, rather than leave it to the OS.
It's not Google. My heuristic is that the bigger the tech giant the more sophisticated, indirect, and obfuscated the sharing/selling of data.
The fact that Google has incurred over $3 billion in fines in recent years specifically for infringing people's privacy should be a consideration!
Yeah, Android is Google
does android not allow you to configure a custom DoH resolver? could Mozilla simply offer a public resolver, and encourage users to switch at the OS level (possibly including a first-launch dialog offering to set the configuration for you)?
You can set DoH in all major browsers in desktop. On iOS, you can use private relay.
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.
I have long been using my own recursive DNS server through Wireguard on my GrapheneOS device. I don't see how using DoH through one of the few well known centralized providers is better for privacy.
Any domain could instrument their DNS to associate your DNS servers with your sessions which is highly unique for you and possibly connects your otherwise distributed devices, it would be odd to me if none of them try to add this to a profile for you just with the expectation of clustering users by more typical configurations.
What's the good DoH provider nowadays? I feel like cloud flare has some downsides in terms of centralization
For those wanting a bit of privacy, you can run your own DOH server[0]. Be aware that the upstream requests can still be tracked, but additional safety steps can be taken such as hosting your own dns resolver (bind/powerdns), sending dns/doh queries over a vpn or tor connection, or spanning queries over multiple sources. Each has its own security and privacy implications, which is beyond the scope of this comment :)
[0] https://github.com/DNSCrypt/doh-server
Running your own DOH server comes with it's own set of risks, depending on your adversary. If you're the only person using a DOH server, then any requests that server make must belong to you. I'd argue that it's better to use a public server and hide in between the other users.
My main issue with DOH is failing to honor my internal DNS overrides to provide local addresses for services on my local network (externally the DNS entries point to the external address but internally the LAN address) It is so annoying fighting against DOH for this
Wikimedia runs an experimental DoH server, see: https://meta.wikimedia.org/wiki/Wikimedia_DNS
Mullvad runs a privacy-oriented DoH service, which is free to use regardless of whether you use their VPN service.
https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
Mullvad DoH is great, and things like ad-blocking seems to be more effective on Mullvad.
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.
> Avoid Cloudflare. They log traffic.
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?
> 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.
For Germany/EU there is ffmuc: https://social.ffmuc.net/@freifunkMUC/114087819103432120
Hopefully we will see more regional DOH providers instead of centralized ones.
Quad9 (supports DoH,DoT,Dnscrypt) and Mullvad are both good secure DNS services.
Choose Quad9 if you want better security and Mullvad for it's adblocking options.
NextDNS is great
I did setup AdGuard with unbound. Setup supports DoH and DoT. Pretty nice.
I like quad9
>DNS query [...] in the clear. [...] (DoH) plugs this privacy leak [...] no one on the network, not your internet service provider [...] can eavesdrop on your browsing
Whoever could see DNS traffic can still see the target you're connecting to...
The promise is especially dangerous when a huge fraction of traffic doesn't use Encrypted Client Hello, [1] so the domain name is sent in the clear with the initial request to the server.
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
But if that request is going to a large provider (GCP, AWS, CloudFlare), without the hostname, the request is going to be close to meaningless for the snoop.
Correct - that would be visible via ClientHello. But Firefox also enabled ECH (when DoH is enabled) a while back - https://support.mozilla.org/en-US/kb/faq-encrypted-client-he... .
also this: https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
This is correct. The right way to think of DoH is as part of a package of mechanisms (including ECH) that collectively are designed to close network-based leakage of browsing history. Used alone, it has some value but that value is limited.
Does anyone know how to force disable DoH on a network?
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.
Outside of IP-blocking known popular DoH hosts (e.g. https://github.com/jameshas/Public-DoH-Lists, and even then it's not the best since there's overlap with popular DNS hosts like Cloudflare), there's no good way to do it without break-and-inspect. That's because DoH is TLS traffic over 443, just with DNS inside instead of HTTP.
It should be possible to have a firewall rule to default deny outgoing connections and a DNS resolver that tells the firewall to allow a connection only after it has resolved it, but I don't know that there's anything off-the-shelf to do this yet. I imagine DoH providers are also either using known SNIs or ESNI, so you could block both of those.
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.
DoH is a technical win but a practical regression for anyone who actually runs their own DNS. With classic DNS, you could hand out your resolver via DHCP and transparently control local zones. With DoH, that's gone. You have to configure each client explicitly, because the traffic is wrapped in HTTPS and can't be intercepted.
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.
Why did Firefox choose to implement DNS over HTTPS (DoH) instead of DNS over TLS (DoT)? Doesn’t HTTPS add an extra layer for DNS queries?
Firefox is a browser and so (1) people at Mozilla are comfortable with HTTP and (2) there has been a lot of investment in making the HTTP stack good. You will also notice that the lead author of DNS over HTTPS [0] was a Mozilla employee.
[0] https://datatracker.ietf.org/doc/html/rfc8484
Some ISPs block DNS except to their own resolvers.
I believe it's easier to hide in regular traffic.
DoH centralizes DNS traffic at a few DoH resolvers. Bad thing.
Actually, DoH doesn't change the situation here one way or the other, it's just a transport. It's true, that Firefox's approach to DoH ("trusted recursive resolver") does. centralize traffic some, but DoH need not be deployed this way. For example, Chrome does what's called same provider auto upgrade, which doesn't change the resolver, but just tries to use DoH if available.
One approach to mitigate this is to spread the queries to multiple DoH providers: https://www3.cs.stonybrook.edu/~mikepo/papers/k-resolver.mad...
I'm not sure that this mechanism delivers the desired privacy benefit, and it's quite hard to make sure it does so.
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.
I wonder why DOH is in the intro described as getting activated by region. Is DoH now active globally for every region, on any (desktop) platform (Mac/Windows) ?
I wonder - whose public keys are needed for this particular DoH implementation to work? How do we know that they're legit?
Update title to include "DNS-over-HTTPS"
Anyone else never seen this acronym for DNS-over-HTTP before?
It's been in the title of the RFC since 2018 and practically every mention I see is formulated as "DNS-over-HTTP (DOH)", so I imagine that's pretty rare.
That took way too long. I was getting so tired of my default ISP's DNS blocking websites it just doesn't like.
[dead]
[flagged]
> If you don't like people seeing your history on the web, maybe think twice about what you do. Maybe you are the problem.
Thanks for your input, google.
Sorry this is Microsoft, I get the confusion.
"if you have nothing to hide" sure sure. show us your history please
Please post your browsing history from your past 14 days to back up your insane hot take.
You first.
Tiresome 0 minute old troll. Disregard.
Kind of wish brand new accounts would get auto-banned if they get comments flagged within a certain timeframe of their creation.
And I wish people wouldn't flag a post because they disagree with it, rather than because it violates the rules.
Yes I agree with that, but most flagged comments I catch usually are pretty blatant violations of the comment guidelines.
It does happen often enough that I kind of wish there was negative flagging weight applied to abusers.
I wished if you made a new account on a platform, you wouldn't automatically be considered a 'troll' if you go against the mainstream narrative.
Very welcoming to new comers.
Firefox for Android is some of the worst software I've ever used. A lot of extensions won't work in it, and even Edge Canary is far better with them. It is extremely slow, and the UI is horrible.
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.
Strange, I am running it on a Snapdragon 8 Gen 2 (Z Fold 5), and it's totally fine for me. (If anything, it's a little too good at staying in the background; if you have private tabs open it insists on persisting in memory.)
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).
I have a OnePlus 5T from 2017 with a Snapdragon 835 processor and find that Firefox works perfectly well on it. I also have a device with a Snapdragon 8cx Gen 3 processor and Windows 11 on ARM. Firefox runs smoothly on that too.
I don't have any issues with it. NoScript and uBlock Origin are working fine for me.
That's pretty harsh. It works fine for me. But even if it didn't, I'd still use it just for uBlock Origin.
Yes. The web, and especially the web on mobile, is unusable without an ad blocker.
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.
For youtube background play Brave is much better.
Edge canary runs on android with full extension support?
Yep. Enable extensions in edge://flags/. Then you can use ublock origin. You can install any crx file extension if you enable developer mode.