51–60 of 121 posts
DoH centralizes DNS traffic at a few DoH resolvers. Bad thing.
Earlier quoted context omitted.
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.
Granted, the os would need to read your address space, not simply supply a recording DNS API, but still...
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.
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.
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 Clou…
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 Clou…
How is the latency?
DoH centralizes DNS traffic at a few DoH resolvers. Bad thing.
One approach to mitigate this is to spread the queries to multiple DoH providers: https://www3.cs.stonybrook.edu/~mikepo/papers/k-resolver.mad...
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.
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?
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 thei…
>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...