Cloudflare DNS resolver for Mozilla is a privacy violation and will kill it's popularity

Mozilla recently announced that it would begin using Cloudflare’s resolver service to look up all queries from the Mozilla browser, even overriding the otherwise default resolver set for the user. 

https://blog.sucuri.net/2017/12/cloudflare-solutions-keylogger-on-thousands-of-infected-wordpress-sites.html

Cloudflare, runs one of the worlds largest networks that powers more than 10 trillion requests per month, which the company says is nearly 10 percent of all Internet requests spanning more than 2.5 billion people worldwide. But big is not always better, as it has been the target of numerous hacks. So what is Mozilla thinking? 

Moreover, your applications shouldn’t be deciding your DNS settings.  No app should be overriding your local DNS settings. Anybody with visibility into your resolver queries knows a lot about your online habits, including what websites you are visiting. T

This is a very serious privacy issue and will lead to many dropping Mozilla as a browser. 

Great articles; 

• https://blog.ungleich.ch/en-us/cms/blog/2018/08/04/mozillas-new-dns-resolution-is-dangerous/
• https://gioxx.org/2018/08/01/firefox-dns-over-https/
• https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/ 

Disabling it this preemptively; 

• Enter about:config in the Mozilla address bar
• Search for network.trr
• Set network.trr.mode = 5 to completely disable it

Feature discussion; 

Daniel Stenberg [:bagder]  at Bugzilla  about the new TRR ( Trusted Recursive Resolver ) says: 

Basic description of experiment: TRR is a separate and parallel way to resolve host names in the browser and the implementation allows for several different operational modes. We want to enable TRR in “shadow mode”, meaning that Firefox resolves all host names using both original native resolver mechanism as well as DNS-over-HTTPS (DOH) but the results from DOH are discarded and are only used for measuring and telemetry. For this experiment, we would use a cloudflare hosted server.

What is the preference we will be changing? network.trr.mode = 4, and network.trr.uri = “https://dns.cloudflare.com/.well-known/dns”

What are the branches of the study and what values should each branch be set to? Two branches: one using TRR, one not. (the one ‘not’ might actually be the control - it would have default prefs. Not sure of shield nomenclature.)

What percentage of users do you want in each branch? 50/50

What Channels and locales do you intend to ship to? Nightly

What is your intended go live date and how long will the study run? 7 days (?)
Are there specific criteria for participants? We want a random distribution to make it possible to assume both branches are sufficiently similar, user wise. Being able to break the data down by very rough locale would be interesting as internet topology will impact performance.

What is the main effect you are looking for and what data will you use to make these decisions? We will look at resolver timings, connection error rates and http response code changes.

Who is the owner of the data analysis for this study? Daniel Stenberg + Patrick McManus

Will this experiment require uplift? No

QA Status of your code: Green, yellow, red. Your code should be QA’d to ensure that changing the preference values has the intended effect you are looking for and does not cause obvious regressions to Firefox. All experiments must pass QA. Depending on the channel/population size a dev QA may be accepted.

Do you plan on surveying users at the end of the study? No.

Link to any relevant google docs / Drive files that describe the project. Links to prior art if it exists:



Details Section for Analysis
For each telemetry probe to be analysed in the study, find it here to determine the following:
Name of probes
DNS_LOOKUP_DISPOSITION
DNS_NATIVE_LOOKUP_TIME
DNS_TRR_RACE
DNS_LOOKUP_ALGORITHM
DNS_TRR_LOOKUP_TIME
DNS_BLACKLIST_COUNT
DNS_TRR_BLACKLISTED
DNS_CLEANUP_AGE
IPV4_AND_IPV6_ADDRESS_CONNECTIVITY
HTTP_RESPONSE_STATUS_CODE
Associated bugzilla thread URL:
e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=

Henri Sivonen (:hsivonen) (a contributor) rational response;

I think we shouldn't run this study in the proposed form. Sending information about what is browsed to an off-path party will erode trust in Mozilla due to people getting upset about privacy-sensitive information (what they browse where "they" is identified by IP address and "what" by host name) getting sent to an off-path party without explicit consent. The policy agreements we have in place with the off-path party won't remove this negative effect, since the way people are known to react this kind of thing isn't in our power to negotiate: people will react to this as a matter of what technically got sent and not as a matter of what the recipient promised not to do. (A browser sending information about what is browsed to an off-path party is the quintessential browser privacy no-no.) (By off-path party, I mean a party that isn't *by necessity* on the network path between the user's computer and the site the user browses. The site can use third-party trackers or infrastructure providers, but that's an action on the site's part--not on the browser's part.) The problem could be addressed in two ways: 1) To study things like end-to-end reachability or round-trip time, Firefox could perform queries for a set of pre-defined names (to remove any correlation with what the user actually browses). This kind of thing has successful precedent as part of TLS 1.3 handshake studies. 2) To study things under realistic use, we should obtain an explicit opt in specifically for sending DNS queries to Cloudflare. (We should do this even if it introduces a potential bias in the data.)