Mozilla plans to roll out DNS over HTTPS to US users in late Septembe…

archived 9 Jul 2022 12:55:16 UTC
ADVERTISEMENT

Mozilla plans to roll out DNS over HTTPS to US users in late September 2019

Sep 7, 2019
Updated • Sep 8, 2019
Starting in late September 2019, DNS over HTTPS (DoH) is going to be rolled out to Firefox users in the United States.
DNS over HTTPS encrypts DNS requests to improve security and privacy of these requests. Most DNS requests happen in the open currently; anyone listening to the traffic gets records of site and IP addresses that were looked up while using an Internet connection among other things.
DoH encrypts the traffic and while that looks good on first glance, it needs to be noted that TLS still gives away the destination in plaintext.
One example: Internet providers may block certain DNS requests, e.g. when they have received a court order to block certain resources on the Internet. It is not the best method to prevent people from accessing a site on the Internet but it is used nevertheless.
ADVERTISEMENT
DoH is excellent against censorship that uses DNS manipulation.
Tip: check out our detailed guide on configuring DNS over HTTPS in Firefox.
Mozilla started to look into the implementation of DoH in Firefox in 2018. The organization ran a controversial Shield study in 2018 to gather data that it needed for the planned implementation of the feature. The study was controversial because Mozilla used the third-party Cloudflare as the DNS over HTTPS service which meant that all user traffic flowed through the Cloudflare network.
Mozilla revealed in April 2019 that its plan to enable DoH in Firefox had not changed. The organization created a list of policies that DoH providers had to conform to if they wanted their service to be integrated in Firefox.
ADVERTISEMENT
In "What's next in making encrypted DNS-over-HTTPS the Default", Mozilla confirmed that it would begin to enable DoH in Firefox starting in late September 2019. The feature will be enabled for some users from the United States and Mozilla plans to monitor the implementation before DoH is rolled out to a larger part of the user base and eventually all users from the United States.
We plan to gradually roll out DoH in the USA starting in late September. Our plan is to start slowly enabling DoH for a small percentage of users while monitoring for any issues before enabling for a larger audience. If this goes well, we will let you know when we’re ready for 100% deployment.
While DNS over HTTPS will be the default for the majority of Firefox installations in the United States, it won't be enabled for some configurations:
  1. If parental controls are used, DoH won't be enabled provided that Mozilla detects the use correctly.
  2. Enterprise configurations are respected as well and DoH is disabled unless "explicitly enabled by enterprise configuration".
  3. Fall back option if DNS issues or split horizon configuration cause lookup failures.
ADVERTISEMENT
Network administrations may configure their networks in the following way to highlight to Firefox that the network is unsuitable for DoH usage:
DNS queries for the A and AAAA records for the domain “use-application-dns.net” must respond with NXDOMAIN rather than the IP address retrieved from the authoritative nameserver.
How to block DNS over HTTPS
firefox disable dns over https
You have two options when it comes to DoH in Firefox. You can change the default provider -- Cloudflare is the default -- to another provider (for whatever reason) or block the entire feature so that it won't be used.
If you don't want to use it, set the value of network.trr.mode to 5 on about:config.
Now You: What is your take on DoH and Mozilla's implementation?
ADVERTISEMENT
Summary
Mozilla plans to roll out DNS over HTTPS to US users in late September 2019
Article Name
Mozilla plans to roll out DNS over HTTPS to US users in late September 2019
Description
Starting in late September 2019, DNS over HTTPS (DoH) is going to be rolled out to Firefox users in the United States.
Author
Publisher
Ghacks Technology News
Logo
Ghacks Technology News
Advertisement

Comments

  1. Haakon said on September 7, 2019 at 7:58 pm
    Reply
    I’ve been using Firefox’s DoH for well over a year and since early this year without the fallback and settling on https://cloudflare-dns.com/dns-query because of ESNI.
    Also on my Android devices via AdGuard’s DNS filter settings for a long time; I forget when they rolled that out. (Settings for DoH, and DoT I think, are available in Android 9.)
    Never any problems with Cloudflare. Otherwise, my Windows systems DNS is Cloud9.
  2. Jonas said on September 7, 2019 at 8:23 pm
    Reply
    This article unfortunately leaves me with more questions than answers.
    Do I understand correctly that DoH does not prevent my ISP from seeing what websites I’m going to? So its only utility is to prevent random MITM spying?
    My Firefox about:config setting for network.trr.mode is currently set to “0”, which is identified as “default”… on the other hand, in my Mac’s Network (system-level) preferences, my DNS servers list starts with “1.1.1.1” (Cloudflare) as the preferred server. So is my browsing (via Firefox) protected with DoH or not?
    Also, would an alternative scheme like DNSCrypt provide more protection, such as privacy from ISP snooping? Is there any support for this in Firefox, perhaps via an extension?
    Is there anything I can do in uBlock Origin settings that would affect this?
    Thank you for any clarifications…
    Jonas
    1. beemeup5 said on September 8, 2019 at 10:34 am
      Reply
      For an encrypted connection, your ISP can only see your DNS queries if you use your ISP’s own DNS resolver. If you use another DNS resolver like OpenDNS (208.67.222.222) or Cloudflare’s DNS (1.1.1.1), then only OpenDNS or Cloudflare would know your DNS queries because they are the ones doing the IP address translations, not your ISP. (Note: “encrypted connection” here means the entire connection is secure via VPN or other secure tunnel, not regular HTTPS. If just using HTTPS, your ISP will always be able to see the main domain host you connect to, but they cannot see full page addresses i.e. full site URLs, only the host part is seen. DoH is meant to obfuscate even the host domain when using HTTPS, but as the article states, the destination is still in plaintext, so your ISP could still see that you connected to Cloudflare DNS or OpenDNS etc.)
      Some VPN services roll their own DNS resolvers, so there’s yet another option to consider. If you’re using a VPN, using the VPN provider’s own DNS resolver will usually give you the best performance (slightly less latency) since your DNS query will not need to bounce to another location before going back through your VPN. (This is all assuming you don’t have some kind of DNS leak in the chain. There are various sites which allow you to test for DNS leaks like dnsleaktest dot com.)
      For an unencrypted connection, your ISP can technically observe whatever you do, but unencrypted connections are basically assumed to be public anyway.
      In my opinion, DNS encryption, be it DoH, or DNSSEC, or DNScrypt, etc is largely a moot exercise. In any restrictive environment, you are always better off encrypting the entire connection, rather than just web browser traffic. OpenDNS, Cloudflare DNS, Google DNS, etc, all process billions upon billions of queries every day non-stop 24/7. Even if they somehow manage to log and monitor all that, gleaming anything meaningful from that mountain of raw input is a lost cause. Your traffic is a needle in the ocean, and all a would-be adversary would be able to obtain should they comb that ocean using their supercomputer are the main host domains you connect to. The value of such information is not worth the resources required to obtain it.
      This is why DNS encryption adoption hasn’t taken off like VPN usage has. Anyone who really needs or cares about security and privacy would simply encrypt the entire connection. And for those who don’t need such security, the risks to privacy exploitable purely through DNS are negligible. How many people have you heard of who had their lives or reputation ruined because some bad guy intercepted their DNS queries and only their DNS queries? No one? That’s what I thought.
      1. Anonymous said on September 8, 2019 at 4:26 pm
        Reply
        > DoH is meant to obfuscate even the host domain when using HTTPS, but as the article states, the destination is still in plaintext, so your ISP could still see that you connected to Cloudflare DNS or OpenDNS etc.)
        And much more importantly, except in the minority cases where https+(Name-based virtual hosting)+TLS1.3+ESNI were all in use for the connection, your ISP can still see that you connected to example.com or controversial-site.com too, even if it didn’t get the DNS query. Because TLS give the destination in plaintext to the ISP not just when you connect to the DoH server, but also when you connect to the actual site you want to visit.
      2. Anonymous said on September 8, 2019 at 5:14 pm
        Reply
        > Even if they somehow manage to log and monitor all that, gleaming anything meaningful from that mountain of raw input is a lost cause.
        > The value of such information is not worth the resources required to obtain it.
        They have the necessary resources, they are not hiding that they are logging and monitoring all that, even if they claim that it’s for good purposes only:
        > Cloudflare will retain only limited transaction data for legitimate operational and research purposes, but in no case will such transaction data be retained by Cloudflare for more than 24 hours.
        Mass surveillance is a thing. And in post-Snowden times, you can’t even say it’s a “tinfoil hat conspiracy theory”.
        > How many people have you heard of who had their lives or reputation ruined because some bad guy intercepted their DNS queries and only their DNS queries? No one? That’s what I thought.
        When people have their lives or reputation ruined, is there always an official press release from the repression forces explaining that this happened, that they did it, why they did it, and what technical data was used to find the target ? The idea would be comical.
        Don’t you think that it’s interesting to know for those repression forces who visits sites deemed “terrorist”, “extremist” or whatever ? Or any illegal site for that matter… I can’t believe you consider this not very valuable data for them.
      3. beemeup5 said on September 10, 2019 at 9:37 am
        Reply
        > Cloudflare will retain only limited transaction data for legitimate operational and research purposes, but in no case will such transaction data be retained by Cloudflare for more than 24 hours.
        > Mass surveillance is a thing. And in post-Snowden times, you can’t even say it’s a “tinfoil hat conspiracy theory”.
        Cloudflare only logs limited transaction data because they cannot log ALL the data. Cloudflare is NOT the NSA. What the NSA has accomplished is NOT trivial. If you had a deeper understanding of what it costs to build an AWS-level datacenter and constantly expand storage for an internet that is expanding EXPONENTIALLY year on year, in addition to the electricity costs to power and cool said datacenters, you wouldn’t think every internet company can just simply do as the NSA does while also doing their “day job” on top of that. The NSA can do it because they have a near bottomless budget and with the way FISA courts operate, they are effectively above the law. Cloudflare? Not so much.
        > When people have their lives or reputation ruined, is there always an official press release from the repression forces explaining that this happened, that they did it, why they did it, and what technical data was used to find the target ? The idea would be comical.
        There are case studies and analyses of security vulnerabilities being exploited in the wild being published regularly. This is often how the community becomes aware that such security vulnerabilities exist in the first place.
        > Don’t you think that it’s interesting to know for those repression forces who visits sites deemed “terrorist”, “extremist” or whatever ? Or any illegal site for that matter… I can’t believe you consider this not very valuable data for them.
        And what kind of person would visit an unsanctioned or illegal site via unsecure connections? Only scrubs who don’t know better, aka low-priority targets for governments and easy targets for law enforcement. No one worth anything is relying solely on DoH, or DNSSEC, or DNSCrypt, etc and calling it a day. DNS encryption is largely pointless. That was my point and it still stands.
      4. Anonymous said on September 10, 2019 at 3:00 pm
        Reply
        > Cloudflare only logs limited transaction data because they cannot log ALL the data.
        Even assuming that what you say is true, even if a fraction of data is monitored, it’s enough to be a threat. If they can collect enough data to do research on it as they claim, they can collect interesting data for the NSA too.
        > they are effectively above the law. Cloudflare? Not so much.
        The law is not preventing other big US tech companies from collaborating with the NSA for mass surveillance. Why would Cloudflare be an exception ? Their position as an ubiquitous MITM reverse proxy, especially for shady sites, and soon ubiquitous DNS provider makes them a treasure trove for State snoopers. For the MITM part, the mass surveillance disclosures even exposed that enrolling surveillance target sites in web services was part of the surveillance strategy.
        > DNS encryption is largely pointless. That was my point and it still stands.
        I agree that DNS encryption is largely pointless but for another reason, because, once again and again, in most cases it won’t even hide the destination from the ISP, and of course the DNS provider will have the data in clear text. What I am saying is that our privacy should be protected from the Cloudflare DNS endpoint.
        > There are case studies and analyses of security vulnerabilities being exploited in the wild being published regularly. This is often how the community becomes aware that such security vulnerabilities exist in the first place.
        Cloudflare does not need to exploit security vulnerabilities, they have the data in clear text with their DNS servers. I was talking about the DNS endpoint, not MITM interceptors of encrypted DNS queries (which, again, in most cases don’t even need to MITM intercept because they see the destination in clear text through other channels).
        > And what kind of person would visit an unsanctioned or illegal site via unsecure connections? Only scrubs who don’t know better, aka low-priority targets for governments and easy targets for law enforcement.
        Not everyone knows that the legal sites they visit are unsanctioned, may cause increased surveillance, and even repression (and by the way the secure connections, as you define it, like with using a VPN, are not obviously making surveillance that much harder). You’re assuming that all the potential targets of surveillance are aware of it and use advanced anonymization techniques, but this is naive, in times where surveillance is so cheap and where it has been disclosed that ethics won’t stop them, only the costs. It has also been disclosed that being part of a minority progressive organization can be enough to be the target of surveillance.
        Also, that there is a cam in my bathroom I can’t get rid of shouldn’t be an argument for me to accept a cam in my bedroom too, just because they already have the bathroom data.
        > No one worth anything is relying solely on DoH, or DNSSEC, or DNSCrypt, etc and calling it a day.
        I do not even consider DoH or DNSCrypt as a privacy measure, as I’m discussing privacy from the DNS provider endpoint, and (again), in most cases DNS encryption won’t hide the destination from the ISP.
        Furthermore, DNSSEC is even less directly related to the privacy of the DNS query from anyone, since it’s not even encrypted, and useful for its authentication only.
      5. beemeup5 said on September 11, 2019 at 9:21 am
        Reply
        As with everything, there are limits.
        Most rational people stop playing the perpetually escalating paranoia game when they realize that the only logical conclusion is to become a hermit in the woods. Even the most fearful and cynical among us would not believe that to be a practical solution. So somewhere between a life in the woods and a life under the ever present “protection” of the State lies a delicate compromise.
        By the very nature of what it is, a communicative system can never be completely private or secure. There are always compromises between convenience and security, between availability of access and privacy. Society itself is a communicative system. Away from all the wires and nodes lies a world you still have to enter with your physical body, where your interactions are entirely public and often recorded via cameras not least of which are the ones in every single person’s hands. There has never been, nor ever will be, a guarantee of safety or privacy. As you can see the public, the public can see you. The internet is but a virtual public space, and yet it has somehow given rise to the modern delusion that true anonymity is possible. True anonymity will never be possible not because of some technological limitation but because of the necessities of interactions. To see it another way, privacy is only a scale of isolation. Perfect privacy requires complete isolation. Excepting that, there are compromises, and there are limits.
        Not saying to throw caution to the wind on the internet, but at the end of the day there’s only so much you can do. You limit trust wherever possible and take security and privacy into your own hands to the best of your ability, but for the rest you let nature take its course. I can’t help that all my personal information is likely out there due to the Equifax breach and countless other breaches that have happened in my state and will undoubtedly continue to happen.
        If there is but one comforting thought, it is that regardless of whether or not I’m here, the world will continue to spin and the sun will rise to another day. Take a deep breath and continue with your path. If one day the State comes knocking, that may be when your story ends, but today is not that day.
      6. Anonymous said on September 11, 2019 at 1:13 pm
        Reply
        > Most rational people stop playing the perpetually escalating paranoia game when they realize that the only logical conclusion is to become a hermit in the woods
        I agree that full privacy is impossible today without becoming a hermit in the woods, but it doesn’t mean that we shouldn’t resist what weakens privacy, and that we shouldn’t make surveillance more costly, when it’s much easier to do than by becoming a hermit. For example, by fighting data centralization in the hands of big US corporate monopolies, just by not using the Firefox Google default search engine, or not using the future Firefox default Cloudflare DNS.
  3. chesscanoe said on September 7, 2019 at 9:01 pm
    Reply
    I prefer the worldwide free Quad9 advantages. In all the time I have used it, I have never observed an outage that affected me using it in the US. I do not claim I am an expert in this matter.
    1. trends said on September 8, 2019 at 9:37 pm
      Reply
      @chesscanoe Visited the Quad9 site.
      What are advantages / disadvantages
      over Google’s DNS servers: (8.8.8.8, 8.8.4.4).
      Anybody else w/Quad 9 DNS experience? Martin?
      1. Bill Woodcock said on September 9, 2019 at 11:55 pm
        Reply
        I’m chairman of Quad9’s board of directors. I’d be happy to answer any specific questions about Quad9. The four principle distinctions between Quad9’s recursive resolver and Google’s recursive resolver are that Quad9’s is GDPR-compliant by dint of not collecting any personal information; Quad9 provides malware blocking from twenty different threat-intel services including IBM, Cisco, and F-Secure; Quad9 is much more widely geographically distributed, so provides better performance in places Google doesn’t have commercial incentive to provide service; and Quad9 is a public-benefit not-for-profit, while Google’s purpose is to benefit itself, not you.
  4. Sunny said on September 8, 2019 at 12:04 am
    Reply
    I don’t want it enabled because it causes Firefox to ignore the hosts file which I use to block some websites.
    I assume they will not make the change with a update (no updates planned for the rest of September), but instead use some kind of remote control over Firefox. I may not even get any notification of the change.
    That would mean I would be browsing without the blocks in the hosts file, without knowing it.
    This is why I do not like software makers having so much control over the software I use.
    It is a security problem.
    Mozilla says DoH is a privacy feature, yet they do not care enough about security (privacy), or they would have thought about this problem and built the DoH feature to use the host file.
  5. cl said on September 8, 2019 at 2:10 am
    Reply
    Anyone using cloudflare may as well enable this too:
    network.security.esni.enabled <-set to true
    Other dns providers may support it as well now.
  6. Steve said on September 8, 2019 at 2:14 am
    Reply
    If they plan to make DNS over HTTPS the default they should implement it in a way that the HOSTS file is always query before handling the DNS request. Otherwise, as it is, the HOSTS file becomes useless, so it is a security drawback. In other words, you trade privacy for security.
  7. David said on September 8, 2019 at 4:10 am
    Reply
    @Steve, about:config pref “network.trr.excluded-domains” is set to localhost by default, so it should read the HOSTS file first.
    1. Steve said on September 9, 2019 at 12:07 am
      Reply
      That option is to specify which domains will be handle by the native resolver. In other words, only those domains (localhost, local) will be checked against the HOSTS file, the rest will still use DoH.
  8. Paul T said on September 8, 2019 at 4:29 am
    Reply
    The proper way to explicitly disable it is to set that config to 5, not 0.
    1. Martin Brinkmann said on September 8, 2019 at 7:16 am
      Reply
      Thank you!
    2. Tom Hawack said on September 8, 2019 at 11:18 am
      Reply
      Indeed, network.trr.mode set to 5 = explicitly turned off. By the way,
      – No idea what differentiates 0 (off) from 5 (explicitly off);
      – Firefox’s Policy Templates (I now manage them manually but there is the excellent ‘Enterprise Policy Generator’ extension as a front-end) sets network.trr.mode set to 5 when ‘Disable DNS over HTTPS’ is checked, which is relevant.
      I don’t use and won’t use Firefox’s built-in ‘DNS over HTTPS’ for several reasons:
      1- I dislike the very idea of having two different DNS resolvers, one system-wide and the other, browser-specific;
      2- As mentioned in the article, “DoH encrypts the traffic and while that looks good on first glance, it needs to be noted that TLS still gives away the destination in plaintext.”
      3- DoH bypasses hosts and gives info to yet another party, Cloudflare by default with Firefox’s DoH. Cloudflare as Google are already sufficiently omnipotent to not give them more power.
      4- I use system-wide DNSCrypt-Proxy which is, IMHO, the best method, especially with the DNScrypt-protocol ( see: ‘DNSCrypt v2 vs DNS-over-HTTP/2 : privacytoolsIO’ at https://old.reddit.com/r/privacytoolsIO/comments/7wakeh/dnscrypt_v2_vs_dnsoverhttp2/ ) :
      “DNSCrypt is faster (over UDP, which other options don’t support) and slightly safer than DoH. It was explicitly designed for DNS, doesn’t allow insecure parameters, is way simpler (= reduced attack surface), and has proper padding.
      DNS-over-HTTP/2 is easier to deploy, as it can be served as a web page. But certificate management can be tricky.
      dnscrypt-proxy supports both protocols. Unless one of them gives you systematic issues due to your ISP blocking it, you should just leave them both enabled. dnscrypt-proxy will try all the configured resolvers, and use the fastest ones no matter what the protocol is.
      DNS-over-TLS is useless. It has zero benefits over these, so it is not implemented.”
      Would I use Firefox’s DoH if I didn’t already use DNSCrypt-proxy? No.
      1. Shiva said on September 8, 2019 at 2:24 pm
        Reply
        +1
        Mainly due to the third point.
      2. Tarmin said on September 8, 2019 at 4:15 pm
        Reply
        > 2- As mentioned in the article, “DoH encrypts the traffic and while that looks good on first glance, it needs to be noted that TLS still gives away the destination in plaintext.”
        That’s called SNI and to fight that leak, you need to enable ESNI in Firefox and ESNI will only work if the TRR mode is set to 2 or 3
      3. Tom Hawack said on September 8, 2019 at 7:24 pm
        Reply
        @Tarmin, thanks for the information. I searched for available info about ESNI and from the little I’ve discovered, in particular at https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
        – it’s only effective with Cloudflare : “ESNI is currently in an experimental phase. Only users of test versions of Firefox will be able to use it, and initially only when accessing services hosted by Cloudflare.”
        – and when it comes to Cloudflare : “Hosting providers and CDNs (like Cloudflare) still know which sites users access when ESNI is in use, because they have to serve the corresponding content to the users. But significantly, ESNI doesn’t give these organizations any information about browsing activity that they would not otherwise possess—they still see parts of your Internet activity in the same way either with or without ESNI.”
        I don’t see the real point, at this time anyway. Certainly interesting when ESNI will be effective with other servers than those of Cloudflare.
      4. Tarmin said on September 9, 2019 at 8:08 am
        Reply
        It’s for bypassing censorship/blockade from ISPs, You don’t need to use VPN anymore with DoH + ESNI. Get it ?
      5. notanon said on September 9, 2019 at 12:43 pm
        Reply
        @Tarmin, thanks for saving me from posting the same.
        You totally schooled @Tom Hawack on ESNI + DNS over HTTPS.
        Tom Hawack is a endless spouts useless information and conspiracy theories all the time.
        I wonder why he’s so paranoid?
        SMH.
      6. Cigologic said on September 9, 2019 at 12:46 am
        Reply
        > Tom Hawack: “No idea what differentiates 0 (off) from 5 (explicitly off)”
        • “5” = off by user’s intention
        ⇒ “I really really do NOT want to use Firefox’s DNS-over-HTTPS.”
        • “0” = (currently) off by default
        ⇒ “What is network.trr.mode or DNS-over-HTTPS ? Oh nevermind, I don’t care anyway.” — ie. probably the majority of users
        My guess for the presence of 2 options with the same effect is that Mozilla might have plans to enable DNS-over-HTTPS by default globally in the future, upon which …
        • If Firefox detects network.trr.mode = 0, it would switch the value to the fail-safe option “2” (use DNS-over-HTTPS, with fallback to using system’s DNS resolver).
        • If Firefox instead detects network.trr.mode = 5, it would respect this intentional user choice.
        For both of the above cases, “0” would be removed, & thus no longer has any effect (whether on or off) even if user subsequently changes it to “0” by error or by intention.
        > Tom Hawack: “I don’t use and won’t use Firefox’s built-in ‘DNS over HTTPS’ for several reasons […] I use system-wide DNSCrypt-Proxy”
        Never say never ? :) You might possibly encounter a situation where it is preferable to use Firefox’s DNS-over-HTTPS feature — for instance, if you use portable Firefox on a public or someone else’s PC, where you lack the rights to change the system’s DNS resolver, or use DNSCrypt-Proxy.
        In which case, you might wish to enable DNS-over-HTTPS by setting:-
        • network.trr.mode = 3
        ⇒ use DNS-over-HTTP only, don’t (immediately) fallback to using host system’s DNS resolver
        • network.trr.uri = https://dns9.quad9.net/dns-query
        ⇒ or: full web domain of your preferred public DNS resolver
        ⇒ default: https://mozilla.cloudflare-dns.com/dns-query
        • network.trr.bootstrapAddress = 9.9.9.9 (= secure dns9.quad9.net)
        ⇒ or: IP address of your preferred public DNS resolver
        ⇒ IP address is for primary fallback, in case the specified DNS resolver’s web domain can’t be resolved. If left blank, Firefox will fallback to using the host system’s DNS resolver (which may or may not be acceptable to you for privacy & security reasons).
    3. Haakon said on September 9, 2019 at 9:46 pm
      Reply
      A pretty good explanation for network.trr.mode:
      0 – Off (default). use standard native resolving only (don’t use TRR at all)
      1 – Race native against TRR. Do them both in parallel and go with the one that returns a result first.
      2 – TRR first. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
      3 – TRR only. Only use TRR. Never use the native (after the initial setup).
      4 – Shadow mode. Runs the TRR resolves in parallel with the native for timing and measurements but uses only the native resolver results.
      5 – Explicitly off. Also off, but selected off by choice and not default.
  9. notanon said on September 8, 2019 at 5:24 am
    Reply
    Fantastic!
    If everyone uses DNS over HTTPS, my uniqueness will be lower (harder to track).
    @pants, when will the gHack user.js begin implementing DNS over HTTPS??? Firefox is more secure with DNS over HTTPS, and no one relies on host files (I defy you to find any self respecting corporate environment that relies on host files for security, it’s amateur hour for r******).
    Let the Google shills enjoy their spyware browser.
    1. notdefault said on September 8, 2019 at 10:55 am
      Reply
      Wow, try to get mozillas centralized dns collection partner snuck into the user.js config which people come to for privacy. Thats low man. Cloudflare IS the MiTM spyware, centralising collection of browsing data to a huge us company..
      please @pants dont default this on in your user.js. Actually hope its set to off there and preferably Ublock would default it off for everyone too.
      1. Tom Hawack said on September 8, 2019 at 2:14 pm
        Reply
        Latest ‘earthlng user.js v69.0-beta’ at https://github.com/ghacksuserjs/ghacks-user.js/releases/tag/v69.0-beta continues to offer the following rules/documentation for Firefox’s DNS-over-HTTPS :
        /* 0707: disable (or setup) DNS-over-HTTPS (DoH) [FF60+]
        * TRR = Trusted Recursive Resolver
        * 0=off, 1=race (removed in FF69), 2=TRR first, 3=TRR only,
        * 4=race for stats but always use native result (removed in FF69)
        * [WARNING] DoH bypasses hosts and gives info to yet another party (e.g. Cloudflare)
        * [1] https://www.ghacks.net/2018/04/02/configure-dns-over-https-in-firefox/
        * [2] https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ ***/
        // user_pref(“network.trr.mode”, 0);
        // user_pref(“network.trr.bootstrapAddress”, “”);
        // user_pref(“network.trr.uri”, “”);
        So it’s up to everyone to make a choice.
      2. Anonymous said on September 8, 2019 at 4:11 pm
        Reply
        The ghacks user.js does not currently modify the default Firefox Cloudflare DNS setting, which is default off:
        It does give a warning that the Cloudflare DNS “gives info to yet another party (e.g. Cloudflare)”, and let me insist on the “yet”, which I believe is intended to remind that it will often hide nothing from your ISP, just give the data to Cloudflare too, resulting in a privacy loss even if for some reason you trust Cloudflare more than your ISP. It is unfortunate that it does not give links focused on explaining this major problem that Mozilla and Cloudflare swept under the carpet, those companies dishonestly pretending that the Cloudflare DoH would increase privacy and that it was even the main motivation for it.
        When Mozilla makes it default on (as their employees have sometimes in the past denied they would, claiming it was only a study…), this will be an interesting test of whether the ghacks user.js can still be trusted, by setting network.trr.mode on 5 (Cloudflare DNS disabled).
    2. Tom Hawack said on September 8, 2019 at 7:23 pm
      Reply
      @Tarmin, thanks for the information. I searched for available info about ESNI and from the little I’ve discovered, in particular at https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
      – it’s only effective with Cloudflare : “ESNI is currently in an experimental phase. Only users of test versions of Firefox will be able to use it, and initially only when accessing services hosted by Cloudflare.”
      – and when it comes to Cloudflare : “Hosting providers and CDNs (like Cloudflare) still know which sites users access when ESNI is in use, because they have to serve the corresponding content to the users. But significantly, ESNI doesn’t give these organizations any information about browsing activity that they would not otherwise possess—they still see parts of your Internet activity in the same way either with or without ESNI.”
      I don’t see the real point, at this time anyway. Certainly interesting when ESNI will be effective with other servers than those of Cloudflare.
    3. Pants said on September 9, 2019 at 8:57 am
      Reply
      I have deliberately avoided making any changes to the DoH item in the user.js since first added, as it wasn’t the finished product. I actually personally don’t even want it in the user.js, TBH. Earthlng has kept it up to date with the option changes. I plan to revamp it soon with a little more up-to-date info. But I don’t want to re-invent the wheel when there are thousands of articles about it.
      However, it will not be made active (i.e not commented out) mainly for this reason:
      – In order to use it, you have to use the default TRR (or specify one): and it is not my place to decide who someone else should connect to
      – DoH has uses. I am neither for nor against it: Hence, it will be inactive .. i.e neutral. I only want to provide the information so users are informed and can make their own decisions
      1. Anonymous said on September 9, 2019 at 10:15 am
        Reply
        @Pants: Just to be sure that everybody understood correctly what you said, because “I don’t want it” and “it will not be made active” could refer to the Cloudflare DNS itself or on the contrary to user.js lines that disable it, the double negative could apply or not to “commented out”, and “it will be inactive .. i.e neutral” could actually mean that the DoH will be active: when Mozilla makes Cloudflare DNS the default, will you disable it (network.trr.mode=5) or not ?
        I read what you wrote as “I will not disable the Cloudflare DNS when Mozilla makes it the default”. Letting Mozilla enable the Cloudflare DNS by default is not letting users make their own decisions, it’s letting Mozilla make for them a decision that is bad for their privacy. Isn’t the purpose of your project to suggest better defaults to protect the users’ privacy and security ? You removed documentation on how to disable in depth Google safebrowsing, and now that ? Have you lost it ?
      2. Pants said on September 9, 2019 at 12:18 pm
        Reply
        @Anonymous
        > You removed documentation on how to disable in depth Google safebrowsing, and now that ? Have you lost it ?
        I answered this question almost 4 months ago, in anticipation of people just not understanding things: https://github.com/ghacksuserjs/ghacks-user.js/issues/732#issuecomment-496583228 -> “No, I haven’t officially lost it.” Every single decision I can back up with solid practical reasoning, research, testing, and impartiality (although I am not always correct)
        There’s a UI for SB. A single checkbox. There are no privacy or tracking issues with SB (except the real time binary checks, which are still included). The prefs were inactive anyway and have been since it moved to github.
        > Letting Mozilla enable the Cloudflare DNS by default is not letting users make their own decisions
        And neither is me enforcing it off (or on with the default or an alternative TRR). That’s not letting users make their own decisions. Your stance comes from your view that DoH is “bad” to begin with: I’m coming from the point of view that DoH is neither good or bad: it depends on the end-user’s threat model, their setup and so on. It would be irresponsible for me to enforce any change
        @Tom
        > wishing that it doesn’t shrink due to a policy which would consider that only essential settings
        It hasn’t lost any impotence whatsoever. I did a **snappening** months ago based on user feedback and my own vision (removed a lot of enforcing defaults since FF/ESR60, removed a lot of redundant prefs), changed a few active pref values (two really: HWA and HTTP2), changed a few prefs to inactive since they were already covered and just create more barriers to un-breaking things. There is also some risk in enforcing defaults (depending on the pref): as it prevents Mozilla flipping them in cases of emergency (e.g someone else’s repo enforces the default true on some ciphers). I can justify every commit (but happy to be proved wrong if I made a mistake)
        I’m also aware that I do not want this to become an unwieldy behemoth that scares everyone. And by removing the rubbish and tweaking the **template**, I was able to add in [SETUP tags for users to use for troubleshooting and setup: which is a far better solution that trying to provide multiple user.js files (e.g a relaxed one)
      3. Anonymous said on September 10, 2019 at 10:02 am
        Reply
        > There’s a UI for SB. A single checkbox.
        But blanking preferences with URLs is defense in depth, and there are examples, like Pocket, where using the pref to disable it is not enough to avoid Firefox doing connections, the URLs must be blanked too. Defense in depth is a logic you apply everywhere else in the user.js. But you seem to be slowly moving from a “defense in depth” perspective towards a “I trust Mozilla, and if you don’t trust Mozilla, just don’t use Firefox” one…
        > There are no privacy or tracking issues with SB (except the real time binary checks, which are still included). The prefs were inactive anyway and have been since it moved to github.
        Debatable, but at the very least some may not want to connect to Google every 30 minutes in the background. I can understand that you leave the least privacy offending part of SB enabled as a compromise for security as you are doing (even if I disable it all myself), but why totally remove the previously commented documentation about the safebrowsing URL for those who want to blank them in spite of your suggestion not to do it ? Please let the users make their own decisions on this point.
        > And neither is me enforcing it off (or on with the default or an alternative TRR). That’s not letting users make their own decisions. Your stance comes from your view that DoH is “bad” to begin with: I’m coming from the point of view that DoH is neither good or bad: it depends on the end-user’s threat model, their setup and so on. It would be irresponsible for me to enforce any change
        Every single pref your project changes in the user.js is “not letting users make their own decisions” either, and for good reasons. Your project is about taking a stance for privacy and security by suggesting changes. As explained even in the ghacks article above (“DoH encrypts the traffic and while that looks good on first glance, it needs to be noted that TLS still gives away the destination in plaintext.”), a default Cloudflare DNS for all users decreases privacy, whatever the end-user’s threat model and setup is. This choice is very disappointing from your project. I could understand that you don’t want to change the DNS prefs if users modified them themselves, for example by choosing a custom DNS provider for their own reasons, but your user.js is a template, those users wouldn’t apply it blindly .
      4. Tom Hawack said on September 9, 2019 at 10:54 am
        Reply
        @Pants, first: thanks for your work, thanks to you, to Earthlng, to all those on your GitHub repository who debate on Firefox settings and provide Ghacks-user.js accordingly. There’s a lot of work and honesty.
        I’d like to take this opportunity to emphasize on the future of Ghacks-user.js, wishing that it doesn’t shrink due to a policy which would consider that only essential settings (maybe even those which are so obvious they need no commenting) need to be implemented. I appreciate very much the documentation provided by the file’s comments, leaving the user with knowledge and letting him face his choices objectively. Regarding above mentioned ‘0707: disable (or setup) DNS-over-HTTPS (DoH) [FF60+]’ for instance my opinion is that Earthlng’s position is valuable : keep the info, commented, but keep it. Same for other settings : Ghacks-user.js is not only a source of most valuable settings for Firefox it is as well an oasis of documentation.
      5. notanon@gmail.com said on September 9, 2019 at 12:55 pm
        Reply
        @Pants, thanks for responding.
        If you’re going to take an agnostic approach to security/privacy, then you should refrain from the numerous prefs that change the way Mozilla designed Firefox to function.
        The gHack user.js modifies a number of prefs that undermine the security of the browser IMO to placate tin-foil hat conspiracy mined people like Tom Hawack & Reddit.
        Maybe remove the pref that interfere with the core browser functions first, before suddenly becoming “neutral” about prefs.
        Granted, you’re probably the smartest person on the planet when I come to user prefs (outside of the designers of Firefox itself).
        So take my feedback with a grain of salt.
        I do believe modifying the default user prefs can be beneficial, but I don’t subscribe to some of the modifications endorsed by the stable gHack user.js (I haven’t examined version 69 yet).
        Your efforts (along with others) on the gHack user.js is appreciated, but it can be improved IMO (I realize Oakenpants maintains the user.js, BTW, but you’re an influential part of the team).
      6. Pants said on September 9, 2019 at 1:53 pm
        Reply
        > Granted, you’re probably the smartest person on the planet when I come to user prefs (outside of the designers of Firefox itself)
        Earthlng is smarter than me .. at night… mostly
        > The gHack user.js modifies a number of prefs that undermine the security of the browser IMO to placate tin-foil hat conspiracy mined people like Tom Hawack & Reddit
        Then feel free to bring them up on Github. There’s usually a trade-off somewhere (be it with FPing, functionality, security etc), but I strive to not reduce security: or at the very least the risk is minimal.
        At the very least it would get us/me to re-examine them, maybe change them or make the documentation better. I welcome your input.
        > Maybe remove the pref that interfere with the core browser functions first
        That’s so general, I don’t know what to make of it, sorry. Maybe you mean multiple prefs: in which case, the same applies: lets discuss it. e.g webaudio: it’s hardly even used on the web (OpenWMP) except for FPing: so disabling that core functionality has no real world breakage. But yes: disabling APIs or crippling a feature is always a last resort: and it’s unfortunate that some APIs have no real solutions yet such as WebGL. You’ll have to be more specific.
        > I realize Oakenpants maintains the user.js, BTW, but you’re an influential part of the team
        I **am** oakenpants
      7. notanon said on September 9, 2019 at 6:09 pm
        Reply
        @Pants, thank for your reply, I didn’t know you were Oakenpants.
        Yes, it’s “prefs”, somehow I forgot the “s”.
        I understand there are trade-offs, but I honestly am befuddled about some of the knee-jerk reactions to phantom fears that have never appeared in the “wild” & that no security researcher in his/her right mind would entertain as even plausible.
        I’d love to help you on Github, but I don’t have an account there, nor will I ever. Sorry.
        I didn’t want to post anything concrete, because who wants to post about potential ways to screw over people using the gHack user.js?
        I give you a minor example of what I’m referring to (a minor example, so it won’t hurt the people using the gHack user.js).
        Tom Hawack posted here on ghacks (not this article), & apparently some conspiracy theorist on Reddit posted about the unjustified fear that Mozilla AMO would be used to “silently” install “malware” webextensions. I think this is crazy stupid, but whatever.
        You responded by suggesting that you could mitigate the problem by removing Mozilla websites from being whitelisted via the pref permissions.manager.defaultsURL, which points to resource://app/defaults/permissions (the repository of whitelisted Mozilla owned websites), by setting it to “” (which equals blank or empty).
        This change was actually implemented in the gHack user.js.
        Mozilla is never going to silently download a malicious webextension (oh God, I know about Looking Glass, I mean a really harmful webextension. People should have had Firefox Studies disabled).
        AFAIK, by setting permissions.manager.defaultsURL to blank, you disabled the whitelisting of Mozilla owned websites (that Mozilla purposely whitelisted).
        By disabling the whitelist, you have now allowed ANY WEBEXTENSION TO WORK ON FORMERLY WHITELISTED MOZILLA OWNED WEBSITES (such as Mozilla AMO).
        Now someone (any installed webextension) CAN alter Mozilla AMO (or any other website FORMERLY protected by permissions.manager.defaultsURL) to install a malware webextension.
        You took an unwarranted action, based on a scenario that will never happen, to allow a much more likely hijacking vulnerability of the Mozilla AMO to occur (BTW, the normies will be protected, due to Mozilla’s whitelisting in permissions.manager.defaultsURL).
        Whenever you make a change, you should do a turnabout & examine from the reverse perspective, “what will changing this pref allow a hacker to accomplish”.
        The gHack user.js is taking a Jenga approach to security/privacy, taking blocks away from the stack & hoping the whole thing doesn’t topple over. It’s a bad approach for any security focused endeavor, & it’s a bad approach period.
        This is merely a minor example, but there are many more prefs that takes a Jenga block away from the stack, without properly evaluating whether removing said Jenga block is warranted.
        Maybe I’m wrong about the specific pref (you & earthling are the experts, outside of the Firefox team), but the gist of my argument is correct, IMO.
        Please reply to let me know you’ve at least read this post, hopefully before some hacker takes advantage of it.
      8. Pants said on September 9, 2019 at 8:56 pm
        Reply
        > Please reply to let me know you’ve at least read this post
        Yes, I have read it.
        I can’t remember when we put that one in. It wasn’t about allowing extensions to work on AMO etc: that was privacy.resistFingerprinting.block_mozAddonManager (tor uplift) and as a side effect it allowed extensions to work on AMO, so they implemented `extensions.webextensions.restrictedDomains` which is inactive in the user.js
        Looking at the reference: I can honestly say this one came from Earthlng (and I’ll plead guilty to OKing it). But have you actually looked the contents: resource://app/defaults/permissions – at first glance I can’t see any immediate threat there
        Maybe I should revisit that one: and that’s what this has been: years of revisiting in an ever-changing landscape.
        > but the gist of my argument is correct
        I get what you’re saying. No-one is perfect and the user.js is ever-changing
        “Whenever you make a change, you should do a turnabout & examine from the reverse perspective” I always say, when you criticize someone, walk a mile in their shoes… then criticize them, because one: you’ll be a mile away and two: you’ll have their shoes. Been saying that for 30 years: I always try to look at the outcome from all perspectives.
        I did a quick count of prefs: approx 210 prefs get flipped (something like 240 prefs are active and 20 **at least** are at default) – so it’s not surprising that you don’t agree with all of them. No-one does.
        If you won’t throw up a temp github account, consider emailing Martin who will forward it to me, so we can start a discourse. I would love your input.
      9. Martin Brinkmann said on September 9, 2019 at 9:58 pm
        Reply
        I can forward and act as a proxy, no problem.
      10. notanon@gmail.com said on September 10, 2019 at 2:33 am
        Reply
        @Pants, again, thanks for the reply. I don’t want to walk in your shoes, it’s too hard, LOL.
        No, I really appreciate your efforts, maybe I’m being too critical (probably … likely), IDK.
        Unfortunately, there are no post numbers, so I’ll have to quote the post(s) that are relevant.
        In the comments, Tom Hawack posts to @Pants that he wants to run extensions on all webpages, including Mozilla AMO.
        Quote (Tom Hawack) – “I’m confused by what is meant by AMO and by “internal pages”. I guess what we are all striving for is to have Webextensions run on all pages, those (“internal pages”?) where they are blocked included.” (end of Quote[Tom Hawack]).
        @Pant respond with a mitigation that ends up in the gHack user.js.
        Quote (@Pants) – BE aware that is supposedly a very very very tiny risk of silent installs via AMO if .. IF .. you have a rogue extension(?) already installed, it can now inject rogue scripts on the page .. AND … you allow service workers – which means you can be fubared, or something – f*d if I know. To mitigate that you can set the following
        /* 2610: remove special permissions for certain mozilla domains (FF35+)
        * [1] resource://app/defaults/permissions ***/
        user_pref(“permissions.manager.defaultsUrl”, “”);
        Now AMO is no more dangerous than any other web page
        With the block_mos pref AMO is no longer “privileged content” and behaves like a normal web page and you can use your gestures, styles, uBo & uMatrix blocks etc – have fun. (end of Quote [@Pants]).
        So Tom Hawack didn’t reference the silent install theory (that I remembered), but it was mentioned by @Pants.
        @Pants you minimized the potential security implications & added that allowing service workers would be needed (but I haven’t read anything about the necessity for service workers to be active as a prerequisite for what you refer to as “rogue” webextensions to install malware via AMO after whitelisting has been disabled).
        Here’s where I disagree, I believe it’s a valid concern & ironically a Firefox employee seems to agree. AFAIK, removing the resource://app/defaults/permissions (via changing the pref to BLANK) robs Firefox of access to it’s whitelists (it doesn’t know what websites to whitelist; therefore no whitelist). resource://app/defaults/permissions points to a list of all the whitelisted Firefox owned websites.
        AFAIK, once you disable the whitelisting of Firefox’s (whitelisted) websites, then webextension can alter those websites.
        In comments of this Github website – https://github.com/ghacksuserjs/ghacks-user.js/issues/259, you posted the hyperlink to a Reddit post.
        The subject of the Reddit post is somewhat unrelated (& I’m not going to discuss it here), but the Reddit post url is https://www.reddit.com/r/firefox/comments/792209/psa_use_hidden_pref/
        evilpies (a verified Firefox Engineer, according to Reddit) posts that enabling webextensions on Mozilla AMO is a security risk. Granted, he’s responding the setting the pref privacy.resistFingerprinting.block_mozAddonManager to “true”, but disabling Mozilla’s whitelisting model altogether by setting permissions.manager.defaultsUrl to “” (blank) accomplishs the exact same outcome.
        Quote (evilpie, verified Firefox Engineer) – To spell it out: THIS IS A SECURITY RISK. Accessing AMO bypasses the permission model of WebExtensions. It allows extensions to initiate the installation of any add-on and query installed extensions. (end of Quote [evilpie, verified Firefox Engineer]).
        AND Quote (evilpie, verified Firefox Engineer) – Thanks for bringing this up. The risk is definitely smaller than it used to be, but people are just going to flip this pref having no idea what it does. (end of Quote [evipie, verified Firefox Engineer]).
        AND Quote (evilpie, verified Firefox Engineer) – Simply because AMO has special permissions around addons that no other site gets. (end of Quote [evilpie, verified Firefox Engineer]).
        I would add, Mozilla AMO has these special permissions FOR A REASON (security, IMO).
        evilpie adds that disabling Mozilla whitelisting weakens add-on security.
        Quote (evilpie, verified Firefox Engineer) – As an implementation artifact this makes privacy.resistFingerprinting stronger by allowing it on AMO, but addon security weaker by also allowing them on AMO. (end of Quote [evilpie, verified Firefox Engineer]).
        BTW, I use gHack user.js in an unusual way, I change each pref individually in about:config or via Windows Group Policy, so I don’t run the gHack user.js the way everyone else does. It’s more work, IMO, but it forces me to examine every pref individually.
        I like your idea of emailing Martin, but (1) I don’t want to setup a burner e-mail account just to e-mail Martin (I won’t use my primary e-mail account for such things, for privacy (dumb, I know, but that’s just me), (2) Martin has censored posts on his website’s comments, so I don’t know if anything I send you (@Pants) will arrive unedited/uncensored to you (maybe crazy, but it’s a concern for me). In fact, my posts are not posted in the comments immediately, there’s a delay (I assume Martin has implemented the delay to actively delete/censor posts or parts of posts that he does not want on his website, which is his prerogative).
        If I figure out a way to contact you @Pants and still keep my privacy/anonymity, then I will let you know about other “disagreements” I have with some of your prefs in the gHack user.js.
        I’m still a fan of the gHack user.js & I will reference it to make changes as long as Firefox exists (hopefully Firefox will, one day, defeat Google’s evil spyware browser.
      11. Pants said on September 10, 2019 at 7:59 am
        Reply
        I remember this now, almost 2 years ago. A lot has changed since then (including code!). No need to mention evilpies is a moz employee a dozen times. That’s not meant to be dismissive of anything he said, or that he is wrong: the exact dates of the comments aren’t super clear: so it’s hard to gauge what was said in what order over a dozen links, and it took months to iron it all out. There was also no consensus in some discussions about this (read the bugzillas). Dude, I was there when it all went down and got cleaned up (not physically). I remember discussing this with at several Tor Uplift engineers [edit … snip snip snip] .. sheesh .. you’re making me reveal some things I simply do not wish to divulge: I’m trying to show you that my many engineers trump your single engineer j/k. I can also quote and reference other mozilla engineers who have a different view on the severity of this to evilpies’ (read the bugzillas).
        I’ll go back over this again in my own time, and re-check with someone… but here’s where I’m at:
        – SWs: from your own link (not sure if that’s where I got the info): https://github.com/ghacksuserjs/ghacks-user.js/issues/259#issuecomment-340629596
        > loophole… Add-ons can register a Service Worker that makes use of mozAddonManager, then once that pref is turned off, the add-on has full access mozAddonManager …
        That loophole AFAIK was closed with extensions.webextensions.restrictedDomains (which is inactive in the user.js – and which I already pointed you to). This is the real ticket you should have been looking at. Not the one you’re linking to https://bugzilla.mozilla.org/show_bug.cgi?id=1406795 which was marked as invalid.
        Even if I am wrong (and I will check again), a lot of factors would have to fall into place to get bitten. You need a rogue extension already installed (feasible: duped end user, it got past AMO etc), it requires SWs (AFAIK, which we have disabled, but sure, a likely candidate to get overwritten), the mozAddons pref and the restrictedDomains prefs both need to be flipped (one of which is inactive) etc. And lastly, a malicious extension can already do all the damage it wants – as stated by other Moz engineers: that AMO is nothing special in this regard (I did say there wasn’t a consensus).
        Also, tell me please, where in the resource is AMO listed? The only three origin urls are discovery, support, and private network. resource://app/defaults/permissions is not what you think it is: and evilpies never mentions it once. You’re conflating two different things.
        Chill out
      12. notanon said on September 10, 2019 at 9:54 am
        Reply
        @Pants, thanks for the reply.
        I’m glad you’re confident it’s okay/mitigated by extensions.webextensions.restrictedDomains, etc.
        I don’t need to “chill out”, I just posted all the links/quote (I really didn’t want to go back & find all those links), because you mentioned that you didn’t see the problem with deleting resource://app/defaults/permissions; otherwise, I wouldn’t even bother to post it.
        Since you asked where in the resource://app/defaults/permissions is Mozilla AMO listed, here’s another (LOL, yes another) url – https://superuser.com/questions/1272531/how-to-change-the-default-local-storage-settings-in-firefox
        Quote (Mike Chapman) If you search for “permissions” in about:config you will find an entry permissions.manager.defaultsUrl. It points to resource://app/defaults/permissions. Enter that into the address bar and hit return, you will see the contents of that internal resource:
        # This file has default permissions for the permission manager.
        # The file-format is strict:
        # * matchtype \t type \t permission \t host
        # * “origin” should be used for matchtype, “host” is supported for legacy reasons
        # * type is a string that identifies the type of permission (e.g. “cookie”)
        # * permission is an integer between 1 and 15
        # See nsPermissionManager.cpp for more…
        # UITour
        origin uitour 1 https://www.mozilla.org
        origin uitour 1 https://support.mozilla.org
        origin uitour 1 https://addons.mozilla.org
        origin uitour 1 https://discovery.addons.mozilla.org
        origin uitour 1 about:home
        origin uitour 1 about:newtab
        # XPInstall
        origin install 1 https://addons.mozilla.org
        origin install 1 https://testpilot.firefox.com
        # Remote troubleshooting
        origin remote-troubleshooting 1 https://input.mozilla.org
        origin remote-troubleshooting 1 https://support.mozilla.org (end of Quote [Mike Chapman])
        As you can see, https://addons.mozilla.org is listed TWICE.
        I believe Mike Chapman (poster on the Superuser.com webpage quoted above) was referencing this blog post (here’s the url) – https://www.mkelly.me/blog/content-uitourjs/
        If I’m not mistaken, I remember seeing a reference to this blog post in the gHack user.js.
        Quote (Michael Kelly) – On my Firefox profile, the “permissions.manager.defaultsUrl” preference is set to resource://app/defaults/permissions:
        # This file has default permissions for the permission manager.
        # The file-format is strict:
        # * matchtype \t type \t permission \t host
        # * “origin” should be used for matchtype, “host” is supported for legacy reasons
        # * type is a string that identifies the type of permission (e.g. “cookie”)
        # * permission is an integer between 1 and 15
        # See nsPermissionManager.cpp for more…
        # UITour
        origin uitour 1 https://www.mozilla.org
        origin uitour 1 https://self-repair.mozilla.org
        origin uitour 1 https://support.mozilla.org
        origin uitour 1 https://addons.mozilla.org
        origin uitour 1 https://discovery.addons.mozilla.org
        origin uitour 1 about:home
        # …
        Found it! A quick DXR search reveals that this file is in /browser/app/permissions in the tree. I’m not entirely sure where that defaults bit in the URL is coming from, but whatever.
        With this, we can confirm that the permissions check is where most valid uses of UITour are passed, and that this permissions file is where the whitelist of allowed domains lives. (end of Quote [Michael Kelly]).
        He’s talking about UI Tour specifically, but the important piece of information is that Firefox looks to permissions.manager.defaultsUrl, which points to resource://app/defaults/permissions, which points to the list of white listed domains (https://www.mozilla.org; https://support.mozilla.org; https://addons.mozilla.org; https://discovery.addons.mozilla.org; etc.).
        If you delete the value “resource://app/defaults/permissions” from permissions.manager.defaultsUrl, then Firefox can’t find the permissions whitelist (effectively disabling the whitelist).
        Again, I’m not arguing with you. You asked where Mozilla AMO is listed and I’m telling you with urls that I have researched to discover the answers myself, since I don’t have access to Tor developers.
        It’s pretty obvious to me that it’s a security vulnerability introduced by the gHack user.js. It’s also obvious that you don’t think it’s a big deal. We disagree. But that’s you prerogative, since you manage the gHack user.js.
        I may have to stop responding with urls & quotes, since it’s rather exhausting to keep posting all of these thing (for your benefit, not mine, since I already know this stuff from researching it myself).
        I’m not trying to win an argument, you will always win the argument, since you manage the gHack user.js.
        I don’t know what the Tor Uplift Engineers told you, I only know what I’ve researched myself (painstakingly), that I am relaying to you.
        I post the urls & quotes not to win an argument (so I don’t have to “chill out”), but to show you that I’m giving you the best information I can (IOW, it’s not my opinion & I’m not pulling this out of my hat).
        If you have any other questions/additional clarifications, please feel free to ask & I “may” (I’m really tired right now) post a reply (maybe without all the urls & quotes next time, because it’s alot of effort).
        Again, thanks for your efforts on the gHack user.js.
      13. Pants said on September 10, 2019 at 6:35 pm
        Reply
        > I’m glad you’re confident it’s okay/mitigated by…
        All those links are old. Like I said, code has changed (not that there was an issue with this file 2 years ago). Go and get Firefox 68+ and look at the contents of resource://app/defaults/permissions and tell where is AMO. It simply isn’t there. And you need to look at the permissions type.
        UI tour is disabled in the user.js, so a broken UI tour is not a problem. Remote trouble-shooting from support.mozilla.org – no thanks. Telemetry from discovery.addons.mozilla.org – no thanks (and addon discovery is disabled), and lastly .. install from private-network.firefox.com – no thanks.
        I’m 99% confident that this was all mitigated with `extensions.webextensions.restrictedDomains` – but I will recheck the current state of things
        It’s not about winning an argument, as you say. I’m not trying to do that either. It’s about getting the information right.
      14. Anonymous said on September 10, 2019 at 11:48 am
        Reply
        > Now AMO is no more dangerous than any other web page
        Besides, the main problem here is not Mozilla installing malware from AMO using its privileged status, because they have already other channels they can use and did use to do that like Studies. The main problem is Mozilla disabling extensions on AMO, especially privacy extensions like content blockers, and at the same time having Google Analytics on it, a real shame for a company that pretends to defend privacy. This problem is aggravated when AMO with unblockable Google Analytics is shown in a browser internal page: then it’s not just a Mozilla site that spies on us while disabling anti-tracking extensions, it’s the browser itself that does it.
        > I like your idea of emailing Martin, but (1) I don’t want to setup a burner e-mail account just to e-mail Martin (I won’t use my primary e-mail account for such things, for privacy (dumb, I know, but that’s just me), (2) Martin has censored posts on his website’s comments, so I don’t know if anything I send you (@Pants) will arrive unedited/uncensored to you (maybe crazy, but it’s a concern for me).
        Sure, it’s a conspiracy. Martin might censor your oh so insightful suggestions before they reach Pants. Time to put on your tinfoil hat just in case.
      15. Anonymous said on September 10, 2019 at 10:30 am
        Reply
        > Mozilla is never going to silently download a malicious webextension (oh God, I know about Looking Glass, I mean a really harmful webextension. People should have had Firefox Studies disabled).
        Stop shilling for a minute.
        Even if you do not think that silent installation of adware is malicious when Mozilla does it, then consider that Mozilla installed the malicious Cliqz spyware too.
        What you actually meant is: Mozilla is never going to install malware, if you were careful enough to opt out of default options that you wouldn’t expect to imply malware installs.
        Well, even that is not granted, after all they happened to do telemetry studies even when users had opted out of telemetry.
        > Now someone (any installed webextension) CAN alter Mozilla AMO (or any other website FORMERLY protected by permissions.manager.defaultsURL) to install a malware webextension.
        As a good shill, you’re ridiculously overblowing a security concern that assumes users have already installed a malicious extension themselves before.
      16. Tom Hawack said on September 9, 2019 at 6:35 pm
        Reply
        @notanon@gmail.com, left aside the vagueness and demagogy of your comment (both quite often tied), just a smile to bounce on your “The gHack user.js modifies a number of prefs that undermine the security of the browser IMO to placate tin-foil hat conspiracy mined people like Tom Hawack & Reddit.”
        The prefs undermine nothing in terms of security, all settings are explained and a substantial effort has been put on those which leave a place for a reasonable doubt. Be as so kind as to give an example.
        Being cautious of the less good and inventive for better settings doesn’t sign a conspiracy mind. Personally I spend quite a deal of time arguing the nonsense of these paranoid state of minds, why they are increasing and how to defeat them with a continuous blend of lucidity and doubt.
        Firefox is a great browser, my default one for quite a deal of time and used ever since its 2.x versions, but there are obviously settings not to mention features which are questionable. So we discuss, here and elsewhere, some of us occasionally or systematically spread hatred and/or quick conclusions. Not all, most of us try to be objective and strive for a better product.
        I think, I hope, we’ve all taken your comment with a grain of salt, understood as peacefully. Yet this peace comes at the end of a comment which is rather vague and slightly aggressive, with a touch of arrogance.
        Keep cool :=)
  10. Jonas said on September 8, 2019 at 6:10 am
    Reply
    @ Steve:
    Are you _sure_ that DNS over HTTPS means the hosts file is bypassed/useless? As I said, my primary DNS server is Cloudflare’s 1.1.1.1 (which may imply DoH?), but my impression was that, at the same time, my carefully crafted hosts file is still active. I’m not certain, however. Can anybody clarify this?
    1. slothy said on September 8, 2019 at 2:23 pm
      Reply
      @ Jonas
      It bypasses the host on mine :(
    2. Sunny said on September 8, 2019 at 4:36 pm
      Reply
      @Jonas:
      Firefox does not use the hosts file when it uses DNS over HTTPS (DoH).
      You can check this yourself adding this line to to the hosts file:
      0.0.0.0 http://www.bing.com
      Next, try to visit http://www.bing.com in Firefox. You wil get a error as it is blocked in the host file.
      Next, enable DoH in Firefox. Options -> General -> Network Settings ->Settings.
      Turn on the “Enable DNS over HTTPS” option.
      Restart Firefox and try to go to http://www.bing.com. Now you will reach the site.
      So the hosts file is no longer used.
      DoH nor HTTPS does not stop your ISP from seeing which site you visit.
      HTTPS does stop your ISP from seeing which webpage on a website you are viewing.
      The mayor benefit that DoH has is that it stops hackers from sending you to a fake DNS resolver that send you to a fake website to steal your login credentials. Hackers can change your DNS resolver by hacking your router.
      But you can prevent such attacks by entering the IP addresses of all critical websites into your hosts file. The hosts file is checked first before using DNS.
      With Firefox no longer using the host file, starting later this month, users who use the hosts file to block malware sites, tracking sites and DNS attacks, will no longer be protected, and will probably not get any warning from the browser about the change. Not many users read all the Mozilla blogs or ghacks to know about it in advance. But many people use the hosts file to block unwanted websites systemwide as it is a simple available feature of the OS.
      So this is a bad move by Mozilla by making it the default:
      They were warned about it too, but choose to ignore the problem:
      https://bugzilla.mozilla.org/show_bug.cgi?id=1511643 and https://bugzilla.mozilla.org/show_bug.cgi?id=1453207.
      1. Steve said on September 10, 2019 at 9:41 am
        Reply
        @Sunny and all:
        And to make matters worse, a malware (PsiXBot) was found doing DoH to connect to its C2C. Meaning now DoH domains for resolvers should be added to the HOSTS file to be blocked. So DoH will not work for any client.
    3. Steve said on September 9, 2019 at 12:15 am
      Reply
      @Jonas:
      Yes, in Firefox once it’s set, all DNS requests go straight to Cloudflare. Now if you configure 1.1.1.1 in your network card as the preferred DNS, that is different. No DoH just standard DNS and the HOSTS file will be checked first by the OS.
  11. Robert said on September 8, 2019 at 7:42 am
    Reply
    As long as my VPN provider supplies it’s own private encrypted DNS, this may be acceptable.
  12. Stv said on September 8, 2019 at 9:28 am
    Reply
    Sad news for those who living in the U.K:
    – Mozilla will not enable this because it makes censorship harder/useless in the U.K.
    :D
    1. Stv said on September 8, 2019 at 10:32 am
      Reply
      The best move from Mozilla so far!
      ISPs (The big boys) were working too hard to poison our DNS queries with ads and logging everything they could.
      Now it seems to be gone but do not worry google solves this, they will implement this and keep selling your data in chromium too with 8.8.8.8 even if they will be fined again for that.
      I think the UK will not be the only country in Europe that will fight against it. telekom & vodafone won’t let this “madness” to happen.
      1. notdefault said on September 8, 2019 at 11:39 am
        Reply
        @Stv how is herding people into centralised collection points for their data a move in the right direction?
        The uk wont fight it, they already backtracked, so it will most likely be back on the schedule to default it there again.
        Moving this feature from the operating system to the app, removes transparency and transfers user control to the app to stealthily do whatever it wants. You cant block it, you wont be able to see or block data collection, the ads will come in soon, and things like ublock will be neutered. You think all this is for the users benefit? Its to restore income for corporations and data bidding.
      2. Stv said on September 8, 2019 at 5:22 pm
        Reply
        I did not recommend cloudflare for a second.
        There is a custom uri field. Those who know what it means will not use cloudflare but the regular users are far more secure than before with their own ISPs.
    2. Anonymous said on September 8, 2019 at 4:49 pm
      Reply
      Mozilla has implemented a “policy detection domain” system in Firefox that will in particular allow the default DNS provider that wants to censor domains, for exemple at the request of the UK government, to automatically disable Firefox’s DoH to allow censorship. A Mozilla proposal from July 2019 said about the intended uses of such a system that:
      > Blocked resource categories can include […] government-unapproved material
      The more public September 2019 announcement of Mozilla on their blog says something different now; that this system should only be used for explicitly opted-in parental controls, and that if they see that it is abused for other reasons, they will revisit they approach:
      > This canary domain is intended for use in cases where users have opted in to parental controls. We plan to revisit the use of this heuristic over time, and we will be paying close attention to how the canary domain is adopted. If we find that it is being abused to disable DoH in situations where users have not explicitly opted in, we will revisit our approach.
      Let’s see how this evolves in the future.
    3. Anonymous said on September 12, 2019 at 4:13 am
      Reply
      They are testing this in the U.S. because that is where Mozilla is situated in, California.
      It will be out for all later down the road.
  13. Paulus said on September 8, 2019 at 10:42 am
    Reply
    Open Firefox.
    Click on the 3 lying dashes in the upper right corner
    The address bar now says: Firefox about: preferences
    In the first menu item, “General” scroll all the way down, until you reach “Network Settings”.
    There you click on “Settings”.
    And in the window that opens (connection settings), tick the box: “Enable DNS over HTTPS”.
    Click on “OK”. For your ISP (Internet Service Provider) you have suddenly become “invisible”.
    If you want to know more about this case, you can take a look here:
    https://www.youtube.com/watch?v=1–MWzrdwxM
  14. JohnIL said on September 8, 2019 at 1:40 pm
    Reply
    Firefox definitely has a grand plan to make the browser the most private out there. Although I doubt a feature like DoH will even be noticed. It’s hardly a selling point that most users could notice or understand its benefits. So far none of this has helped Firefox in marketshare.
  15. jedisct2 said on September 8, 2019 at 2:23 pm
    Reply
    > the destination is still in plaintext, so your ISP could still see that you connected to Cloudflare DNS or OpenDNS etc
    It’s called SNI, and to encrypt that ESNI is being implemented already in Firefox while it’s in W-I-P in Chrome. Your response is not only misleading but filled with biases.
  16. Paul T said on September 8, 2019 at 2:52 pm
    Reply
    Super easy to test, turn DoH on then try to go to a host blocked in your hosts file.
  17. Anonymous said on September 8, 2019 at 4:15 pm
    Reply
    > DoH encrypts the traffic and while that looks good on first glance, it needs to be noted that TLS still gives away the destination in plaintext.
    > DoH is excellent against censorship that uses DNS manipulation.
    Thank you for pointing that the Cloudflare DNS does often strictly *decrease* privacy by sending the data to Cloudflare without hiding it from the ISP, and that alternative DNS are interesting for censorship circumvention, not for privacy: on the contrary, at the cost of privacy.
  18. Dave said on September 8, 2019 at 5:03 pm
    Reply
    Unless every dns is using https this is the opposite of privacy, it’s advanced data collection.
    I’m not going to let Mozzilla route all my DNS requests through a server of thier designation.
  19. Dilly Dilly said on September 8, 2019 at 5:45 pm
    Reply
    Another reason in a long growing list not to use Firefox. I was one of the cool kids using FF back in ’03, people were like ‘wtf is that’ and I was like ‘only the best browza eva’. Abandoned ship in ’11, sayonara mozilla! And btw at some point the control freaks at mozilla will abolish about:config. Think they won’t? FF lost its flavor because too many cooks in the kitchen. That and its run by a pit of greedy ideologues.
  20. John Fenderson said on September 9, 2019 at 3:22 am
    Reply
    “What is your take on DoH and Mozilla’s implementation?”
    I think DoH is a terrible thing that decreases everyone’s security, and have had to go to extra effort to ensure that it’s neutered on my own network. That it’s effectively a standard now means that the cat is out of the bag, and how Mozilla implements it doesn’t matter. The damage is done.
  21. UseYourOwnDNSResolver said on September 9, 2019 at 9:38 am
    Reply
    Running a local DNS resolver is still the best option. All the open DNS resolver nonsense, no matter who runs the server, is just that. And screw DNSoverHTTPs if you care about privacy.
  22. John C. said on September 9, 2019 at 10:55 am
    Reply
    I absolutely do no trust Cloudflare despite their protestations that they’re “good guys”. If Mozilla makes DoH mandatory in Firefox, I’ll find another browser.
  23. Anonymous said on September 11, 2019 at 3:23 am
    Reply
    Some Observations:
    1) Values of 1 and 4 still seem to be accepted for network.trr.mode despite the comments in GitHub’s user.js as shown above – “1=race (removed in FF69)” and “4=race for stats but always use native result (removed in FF69)” – so what does “removed” actually mean?
    2) I would highly recommend testing the effects of network.trr.mode settings other than 0 or 5 to verify that your firewall is not being bypassed without your knowledge. See https://www.zdnet.com/article/mozilla-to-gradually-enable-dns-over-https-for-firefox-us-users-later-this-month/ – “By moving DNS server settings from the OS to the browser level, and by encrypting the DNS traffic, DoH effectively hides DNS traffic from internet service providers (ISPs), local parental control software, antivirus software, enterprise firewalls and traffic filters, and about any other third-party that tries to intercept and sniff a user’s traffic.” and “Companies that provide enterprise traffic filtering solutions have also criticized the protocol, which they said can act as a firewall bypassing mechanism.”
    3) I have seen an apparent firewall bypass with trr.mode=3 and Norton Security Suite (Version 22.18.0.213) on Firefox 67.0.4 and 69.0 on Windows 8.1 Pro. I get different results on Firefox 68.0.2, where trr.mode=3 results in “Hmm. We’re having trouble finding that site.” for all websites, despite having set network.trr.uri and network.trr.bootstrapAddress. Possibly relevant Bugzilla reports are https://bugzilla.mozilla.org/show_bug.cgi?id=1561084 and https://bugzilla.mozilla.org/show_bug.cgi?id=1563173
    4) Some anti-virus/firewall software products (I don’t think Norton Security Suite is one of them) have the ability to intercept HTTPS traffic. It would be interesting to know the effects of trr.mode=3 with those products. A paper from 2017 entitled “The Security Impact of HTTPS Interception” at https://jhalderm.com/pub/papers/interception-ndss17.pdf mentions a number of vendors: Avast, AVG, Bitdefender, Bullguard, ESET, Kaspersky
    5) See https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%5Btrr%5D for the list of trr-related Bugzilla reports
    1. Cigologic said on September 16, 2019 at 1:42 am
      Reply
      > Anonymous: “network.trr.mode […] “1=race (removed in FF69)” and “4=race for stats but always use native result (removed in FF69)” – so what does “removed” actually mean?”
      “Removed” indicates that as of Firefox stable v69.0 (03 Sep 2019) onwards, the values of 1 & 4 no longer have any effect (since Mozilla had already gathered all the test data they require), but are instead reserved for some other potential use in the future.
      Before Firefox v69.0:
      1 – [Race] Query both the system & Firefox’s DNS-over-HTTPS resolvers in parallel, & let Firefox select either one based on which returns faster DNS query responses
      4 – [Shadow] Use the system’s DNS resolver for results, while Firefox’s DNS-over-HTTPS is used to gather timing & measurements data
      From Firefox v69.0 onwards:
      https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode
      1 – Reserved (used to be Race mode)
      4 – Reserved (used to be Shadow mode)
      Incidentally, some enterprise users are seeking (or have already found) ways to block DNS-over-HTTPS, so as to prevent their minions from circumventing censorship.
  24. Anonymous said on September 12, 2019 at 4:14 am
    Reply
    “I don’t trust Cloudflare!”
    Good, that’s smart. But answer me this:
    Do you trust your ISP even more?

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.

Spread the Word

Ghacks Newsletter Sign Up

Please click on the following link to open the newsletter signup page: Ghacks Newsletter Sign up

Recently Updated

0%
 
10%
 
20%
 
30%
 
40%
 
50%
 
60%
 
70%
 
80%
 
90%
 
100%