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.

Brave on iOS is fine. Works roughly like my old Android Firefox did.

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.

Samsung Browser do support few ad blocking extensions like ADB+ and AdGuard

Kiwi browser allows the blocked chrome extensions such as ublock origin

Why not do dns adblocking so the device or browser does not matter

Try lemur browser, it has extension support.

Try Vivaldi

> you could hand out your resolver via DHCP and transparently control local zones. With DoH, that's gone.

Checkout RFC9463

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.

Hey, just wanted to say thanks for your work on Waterfox!

> DoOH

How is the latency?

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.

See: https://educatedguesswork.org/posts/dns-security-dox/ for more on 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 thought Android only supported DNS over TLS, so at least this opens up options for people.

AFAIK Android does not do DoH but DoT - at least you can only set a DoT endpoint in the "private DNS" settings.

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 :)

[0] https://github.com/DNSCrypt/doh-server

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

For Germany/EU there is ffmuc: https://social.ffmuc.net/@freifunkMUC/114087819103432120

Hopefully we will see more regional DOH providers instead of centralized ones.

NextDNS is great

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.

I did setup AdGuard with unbound. Setup supports DoH and DoT. Pretty nice.

I like quad9

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... .

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.

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...

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.

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.

> 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.

"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.

[flagged]

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 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.

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.

Edge canary runs on android with full extension support?