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.
Edge for Android also has (limited) extension support.
It only supports a subset of extensions, but I am using uBlock Origin (full version, although _lite_ is also available), Sponsorblock and Dark Reader for example.
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.
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.
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.
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.
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.
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.)
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.
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 :)
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.
>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...
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.
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.
[+] [-] NdMAND|6 months ago|reply
[+] [-] vanc_cefepime|6 months ago|reply
[+] [-] christophilus|6 months ago|reply
[+] [-] edelhans|6 months ago|reply
[+] [-] okanat|6 months ago|reply
[+] [-] vdfs|6 months ago|reply
[+] [-] antman|6 months ago|reply
[+] [-] that_lurker|6 months ago|reply
[+] [-] vezycash|6 months ago|reply
[+] [-] icar|6 months ago|reply
[+] [-] dingi|6 months ago|reply
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.
[+] [-] j16sdiz|6 months ago|reply
Checkout RFC9463
[+] [-] MrAlex94|6 months ago|reply
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.
[+] [-] mikae1|6 months ago|reply
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.
[+] [-] sersi|6 months ago|reply
[+] [-] temp0826|6 months ago|reply
How is the latency?
[+] [-] LiamPowell|6 months ago|reply
[+] [-] alerighi|6 months ago|reply
[+] [-] thyristan|6 months ago|reply
[+] [-] ekr____|6 months ago|reply
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.
[+] [-] wander_forever|6 months ago|reply
[+] [-] noirscape|6 months ago|reply
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.)
[+] [-] jansper39|6 months ago|reply
[+] [-] Phelinofist|6 months ago|reply
[+] [-] seanieb|6 months ago|reply
[+] [-] drnick1|6 months ago|reply
[+] [-] nemomarx|6 months ago|reply
[+] [-] grepfru_it|6 months ago|reply
[0] https://github.com/DNSCrypt/doh-server
[+] [-] mrweasel|6 months ago|reply
[+] [-] jsheard|6 months ago|reply
https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
[+] [-] miyuru|6 months ago|reply
Hopefully we will see more regional DOH providers instead of centralized ones.
[+] [-] hocuspocus|6 months ago|reply
[+] [-] AlgebraFox|6 months ago|reply
Choose Quad9 if you want better security and Mullvad for it's adblocking options.
[+] [-] Phelinofist|6 months ago|reply
[+] [-] aborsy|6 months ago|reply
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.
[+] [-] afh1|6 months ago|reply
Whoever could see DNS traffic can still see the target you're connecting to...
[+] [-] throw7|6 months ago|reply
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.
[+] [-] xvdAZh|6 months ago|reply
[+] [-] ndriscoll|6 months ago|reply
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.
[+] [-] Aldipower|6 months ago|reply
[+] [-] mentalgear|6 months ago|reply
[+] [-] divbzero|6 months ago|reply
[+] [-] ChrisArchitect|6 months ago|reply
[+] [-] BinaryIgor|6 months ago|reply
[+] [-] quantumwoke|6 months ago|reply
[+] [-] jorams|6 months ago|reply
[+] [-] anon1395|6 months ago|reply
[+] [-] revanwjy|6 months ago|reply
[deleted]
[+] [-] neworder56|6 months ago|reply
[deleted]
[+] [-] dbcooper|6 months ago|reply
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.