_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Firefox 143 for Android to introduce DoH
drnick1 wrote 2 hours 9 min ago:
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.
groggler wrote 4 min ago:
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.
aborsy wrote 2 hours 12 min ago:
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.
BinaryIgor wrote 2 hours 45 min ago:
I wonder - whose public keys are needed for this particular DoH
implementation to work? How do we know that they're legit?
dingi wrote 3 hours 35 min ago:
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.
NdMAND wrote 4 hours 26 min ago:
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.
antman wrote 1 hour 41 min ago:
Kiwi browser allows the blocked chrome extensions such as ublock
origin
twapi wrote 1 hour 16 min ago:
Kiwi is no longer maintained
vdfs wrote 1 hour 58 min ago:
Samsung Browser do support few ad blocking extensions like ADB+ and
AdGuard
okanat wrote 2 hours 38 min ago:
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.
vanc_cefepime wrote 2 hours 44 min ago:
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.
darkamaul wrote 2 hours 8 min ago:
I'm also using Orion on iOS, so far without any major issues.
And adblocking still works great here.
stagalooo wrote 2 hours 19 min ago:
Yes, this is still true. I use orion but I do find it to be a bit
buggy.
vanc_cefepime wrote 1 hour 27 min ago:
Same. This was my reason for going back to safari (now w ublock
lite) but with a dns adblocker like pihole/adguard home.
vezycash wrote 2 hours 46 min ago:
Try lemur browser, it has extension support.
christophilus wrote 4 hours 3 min ago:
Brave on iOS is fine. Works roughly like my old Android Firefox did.
divbzero wrote 4 hours 37 min ago:
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?
ekr____ wrote 4 hours 20 min ago:
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]
URI [1]: https://datatracker.ietf.org/doc/html/rfc8484
SoftTalker wrote 4 hours 29 min ago:
Some ISPs block DNS except to their own resolvers.
pkulak wrote 4 hours 35 min ago:
I believe it's easier to hide in regular traffic.
quantumwoke wrote 4 hours 38 min ago:
Anyone else never seen this acronym for DNS-over-HTTP before?
jorams wrote 4 hours 14 min ago:
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.
anon1395 wrote 5 hours 19 min ago:
That took way too long. I was getting so tired of my default ISP's DNS
blocking websites it just doesn't like.
throw7 wrote 6 hours 3 min ago:
Does anyone know how to force disable DoH on a network?
In [1] 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.
URI [1]: https://support.mozilla.org/en-US/kb/canary-domain-use-applica...
ndriscoll wrote 3 hours 56 min ago:
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.
xvdAZh wrote 5 hours 58 min ago:
Outside of IP-blocking known popular DoH hosts (e.g. [1] , 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.
URI [1]: https://github.com/jameshas/Public-DoH-Lists
ChrisArchitect wrote 6 hours 28 min ago:
Update title to include "DNS-over-HTTPS"
dbcooper wrote 6 hours 32 min ago:
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.
future10se wrote 4 hours 31 min ago:
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).
nemomarx wrote 6 hours 19 min ago:
Edge canary runs on android with full extension support?
dbcooper wrote 6 hours 15 min ago:
Yep. Enable extensions in edge://flags/. Then you can use ublock
origin. You can install any crx file extension if you enable
developer mode.
veyh wrote 6 hours 23 min ago:
That's pretty harsh. It works fine for me. But even if it didn't, I'd
still use it just for uBlock Origin.
SoftTalker wrote 4 hours 25 min ago:
Yes. The web, and especially the web on mobile, is unusable without
an ad blocker.
dbcooper wrote 6 hours 18 min ago:
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.
MaKey wrote 6 hours 27 min ago:
I don't have any issues with it. NoScript and uBlock Origin are
working fine for me.
afh1 wrote 6 hours 44 min ago:
>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...
wander_forever wrote 4 hours 12 min ago:
Correct - that would be visible via ClientHello. But Firefox also
enabled ECH (when DoH is enabled) a while back - [1] .
URI [1]: https://support.mozilla.org/en-US/kb/faq-encrypted-client-he...
wander_forever wrote 3 hours 54 min ago:
also this:
URI [1]: https://support.mozilla.org/en-US/kb/firefox-dns-over-http...
ekr____ wrote 5 hours 9 min ago:
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.
bscphil wrote 6 hours 28 min ago:
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]
URI [1]: https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt...
URI [2]: https://github.com/kpcyrd/sniffglue
kyrra wrote 6 hours 37 min ago:
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.
MrAlex94 wrote 6 hours 46 min ago:
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.
mikae1 wrote 3 hours 45 min ago:
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.
hulitu wrote 2 hours 26 min ago:
> It's been accessible via about:config, yes.
Am i the only one for which about:config does nothing on Firefox on
Android ?
prettymuchnoone wrote 2 hours 13 min ago:
try chrome://geckoview/content/config.xhtml
temp0826 wrote 5 hours 41 min ago:
> DoOH
How is the latency?
martinald wrote 4 hours 17 min ago:
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.
sersi wrote 5 hours 44 min ago:
Hey, just wanted to say thanks for your work on Waterfox!
Aldipower wrote 7 hours 17 min ago:
DoH centralizes DNS traffic at a few DoH resolvers. Bad thing.
ekr____ wrote 6 hours 14 min ago:
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.
mikepo wrote 6 hours 47 min ago:
One approach to mitigate this is to spread the queries to multiple
DoH providers:
URI [1]: https://www3.cs.stonybrook.edu/~mikepo/papers/k-resolver.mad...
ekr____ wrote 5 hours 10 min ago:
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.
mentalgear wrote 7 hours 20 min ago:
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) ?
nemomarx wrote 7 hours 21 min ago:
What's the good DoH provider nowadays? I feel like cloud flare has some
downsides in terms of centralization
Phelinofist wrote 2 hours 23 min ago:
I did setup AdGuard with unbound. Setup supports DoH and DoT. Pretty
nice.
AlgebraFox wrote 4 hours 0 min ago:
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.
hocuspocus wrote 6 hours 49 min ago:
NextDNS is great
mrweasel wrote 6 hours 58 min ago:
Wikimedia runs an experimental DoH server, see:
URI [1]: https://meta.wikimedia.org/wiki/Wikimedia_DNS
grepfru_it wrote 7 hours 0 min ago:
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]
URI [1]: https://github.com/DNSCrypt/doh-server
mrweasel wrote 6 hours 55 min ago:
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.
cortesoft wrote 3 hours 45 min ago:
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
miyuru wrote 7 hours 6 min ago:
For Germany/EU there is ffmuc: [1] Hopefully we will see more
regional DOH providers instead of centralized ones.
URI [1]: https://social.ffmuc.net/@freifunkMUC/114087819103432120
qiine wrote 7 hours 13 min ago:
I like quad9
jsheard wrote 7 hours 17 min ago:
Mullvad runs a privacy-oriented DoH service, which is free to use
regardless of whether you use their VPN service.
URI [1]: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
traceroute66 wrote 7 hours 4 min ago:
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.
pred_ wrote 3 hours 30 min ago:
> 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?
traceroute66 wrote 3 hours 19 min ago:
> 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.
LiamPowell wrote 7 hours 22 min ago:
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?
Phelinofist wrote 2 hours 26 min ago:
AFAIK Android does not do DoH but DoT - at least you can only set a
DoT endpoint in the "private DNS" settings.
wander_forever wrote 4 hours 14 min ago:
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 [1]
.
URI [1]: https://wiki.mozilla.org/Security/doh-resolver-policy
ekr____ wrote 6 hours 16 min ago:
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: [1] for more on the difference.
URI [1]: https://educatedguesswork.org/posts/dns-security-dox/
wander_forever wrote 4 hours 19 min ago:
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.
alerighi wrote 6 hours 30 min ago:
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.
jansper39 wrote 6 hours 37 min ago:
I thought Android only supported DNS over TLS, so at least this opens
up options for people.
noirscape wrote 6 hours 55 min ago:
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]: [1] 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.)
URI [1]: https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the...
izacus wrote 6 hours 35 min ago:
What does your post have to do with DoH though?
noirscape wrote 4 hours 9 min ago:
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.)
thyristan wrote 7 hours 14 min ago:
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.
khc wrote 5 hours 10 min ago:
the browser, being the originator of these DNS queries, already
knows what website you are visiting.
thyristan wrote 5 hours 4 min ago:
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.
seanieb wrote 7 hours 19 min ago:
Privacy.
LiamPowell wrote 7 hours 13 min ago:
Why is DoH in the browser more private than DoH in the OS?
lucideer wrote 6 hours 24 min ago:
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.
e12e wrote 6 hours 4 min ago:
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...
lucideer wrote 4 hours 42 min ago:
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.
cogman10 wrote 5 hours 6 min ago:
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.
DetroitThrow wrote 7 hours 6 min ago:
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.
add-sub-mul-div wrote 7 hours 7 min ago:
It's not Google. My heuristic is that the bigger the tech giant
the more sophisticated, indirect, and obfuscated the
sharing/selling of data.
benoau wrote 6 hours 29 min ago:
The fact that Google has incurred over $3 billion in fines in
recent years specifically for infringing people's privacy
should be a consideration!
ape4 wrote 7 hours 14 min ago:
Yeah, Android is Google
woodrowbarlow wrote 6 hours 48 min ago:
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)?
DIR <- back to front page