The article doesn't suggest there's something sneaky going on. The article is suggesting that Mozilla are choosing to share your DNS queries with a third party service by default, which is exactly what they're doing. It's not about them choosing Cloudflare in particular, it's about them choosing any particular service by default. And the article's argument that, if you have to choose somebody to share this data with, it might as well be the people you already share it with, seems pretty valid to me.
edit: I have to point out that the article has backed away from the claim that this will be enabled by default in September. Looking at the Mozilla blog, they mention wanting to enable this by default but have no actual plan to do so (and more crucially doesn't discuss at all what sort of form it would have to be in for them to enable it by default, it may look nothing like the cloudflare-default we're discussing here).
That’s simply not true. Mozilla is not sharing DNS queries with Cloudfare by default, nor are they overriding your configured DNS servers per default. This is an experimental opt-in feature, and they are also running an opt-in study. There has been no announcement of an ”on by default” for DOH. If you enable the experimental feature there is no default provided and you have to set your own server, but if you opt in to the study, you’ll get Cloudfare. This is almost pure FUD at this point.
Just to be clear, the authors are wrong? There will not be a September patch that overrides my network DNS settings?
"With the next Mozilla patch in September any DNS change you configure in your network won't have any effect anymore, at least for browsing with Firefox, because Mozilla has partnered up with Cloudflare and will resolve the domain names from the application itself via a DNS server from Cloudflare based in the United States."
This is the relevant post from the Mozilla nightly blog: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr... It confirms that the default is off. It also gives a much more nuanced view of the level of partnership. CF is currently the partner for a study regarding that feature. That study still requires opt-in (and currently nightly) The patch in September will bring the feature to mainline FF, but it’s still default off and hidden behind “about:config”
Do you seriously believe that Mozilla is issuing a patch in September that will somehow force you to use Cloudflare as a DNS provider? That 'any DNS change you configure in your network won't have any effect anymore'? Do you know many setups that would break?
> We believe that negotiating a privacy first operating agreement is something that Firefox can do for people that is just impractical to ask them to do for themselves. Imagine calling up your residential ISP and asking them to agree to an audit that demonstrates they do not log your IP address on their DNS server. And then repeating the process for your favorite coffee shop, library, friend’s house — anywhere you and your browser go to connect.
Firefox improves user privacy by default by finding good partners, establishing legal agreements that put privacy first, and eventually shipping a default configuration we believe is best.
They know about the power of default settings - and with the current default, they will be unable to roll-out this feature to a meaningful number of users. So at some point, the default will probably change to activate DoH.
Technically, this isn't "force" as you'll probably be able to turn it back off via about:config - if you know which options to change, what to change them to and if you are willing to click past the "if you proceed, you may damage your computer" warning.
Not every random guest that wants to access your local Nexcloud instance will be willing to do this.
And you expect that to happen within the next month? Without any warning that it will happen with the 62 release? After they have just started an experiment intended to shake down the feature on both the server and the client side? Even after having it default off in nightly? With no practical experience of how a large-scale DoH setup behaves in a real-world environment? Breaking all setups that use an internal DNS to resolve internal names (such as any larger-scale corporate setup)?
If you intend to say “sometime in the unspecified future Mozilla will probably default to this.”, then I’d agree but this is not what’s being discussed. At that point in the future, the whole environment in which this is operating in will look different. More DoH-capable providers, a better understanding of the benefits and drawbacks, a config UI,...
Hmm, looks as if the September date was indeed an error - even the article added a correction. (Also a Mozilla representative seemed to post they plan to keep local DNS as fallback)
So I do hope you're right and they will take their time until the ecosystem stabilizes and they found less damaging strategies.
I still think there are general problems with DoH and the assumption that all local networks are hostile. But maybe, there will be more time to discuss those assumptions.
I don't see that they will necessarily add a config GUI though. Most people will likely ignore the feature and the techies already have about: config, so there might be little pressure to add a more accessible UI.
I don't see how they could enable it by default unless they query both local and DoH at the same time .. or perhaps a hybrid model where they only using DoH by default on certain TLD's and / or domains.
Corporate users would be utterly broken unless their IT staff are managing the proxy settings in all their installed browsers, which is often not the case. This would lead to Security and IT staff blocking CF DNS until it was fixed.
I believe this is a good thing to watch for, but I can't imagine Mozilla not having thought this through.
The default applies currently if you enable an experimental feature. They hammered out a tight privacy agreement for one service and use that as default while this is stabilized. You can pick any other resolver if you prefer. Seems a legit way of handling this.
> And the article's argument that, if you have to choose somebody to share this data with, it might as well be the people you already share it with, seems pretty valid to me.
The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider. It’s not entirely working right now due to SNI being plaintext, but work is being done on that, too. So that’s really not a good argument.
Most Firefox users are absolutely unaffected by this. Literally all people that don’t explicitly enable this. All those who do might want to make up their mind if they want to participate in this and if they want CF to be their provider of trust. Keep in mind that CF will see a substantial chunk of the traffic anyways.
Mozilla seems to be confident in that agreement and I have a certain amount of trust in Mozilla which factors into my decision. Yours might be different, so don’t enable that feature or use a different provider.
FF will turn this on for everybody and Cloudflare will be the default 2018? Don't know. 2019? For sure. All FF browsing meta data flows into the US, the country with the most spies and no legal framework to go to court.
So your argument is an obvious straw man and one wonders about your motivations to support getting all the browsing meta data into the US by default.
Moving my data from Germany to the US will not make me more secure in any way.
And talking about repressed countries is like "think about the children!" for the rest of us - a nice lever to sell this massive data vacuuming.
Why do you believe that this will be default on at any time in the near future without a reasonable configuration UI and without a reasonable set of DoH-capable nameservers? Especially given that this would break a substantial number of existing setupts? If you have this little faith into the FF/Mozilla folks, why do you keep using FF? If you’re not using Firefox, what are you concerned about?
The section of people that use it might benefit to a very large degree. Or they can make the switch prominent to push adoption. There are a lot of features implemented and hidden behind “about:config” where you could ask the same question. Many of them are for the security and privacy conscious but come with a few strings attached, for example some advanced cookie settings such as third party isolation.
That said: I fully expect that at some point Mozilla will want to push adoption of this feature, but not in its most extreme form. I’d expect that a default configuration would use soft fallback.
Which I think is the purpose of almost all experimental feature.
In the blog it is clearly stated that they hope DoH implementations will become standard and common, maybe that even some ISP start offering their own.
Why does so many people distrust every single step done by mozzilla!?
Sorry, this got me emotional, but since I started following tech news few years ago the amount of fake news on mozzilla I read is astounding.
And proper fake news. Many, as this article does, do no claim that a new feature dangerous per se, but falsely (I don't think with purpose, that is what I find astounding) quote mozzilla blogs to build an apocalyptic scenario
In today's world, it's important to remain skeptical of companies who are responsible for how our data and usage statistics are used or shared. Companies have generally shown themselves to be untrustworthy and it's not enough for a company to have been 'good' so far. We need to stay vigilant, even if it is Mozilla.
I believe Mozillas goal is to use the collective bargaining power of it's user-base to get favorable terms and conditions from vendors like cloudflare.
This could include 3rd party reviews, etc.. Who knows?
That wouldn't stop legal threats. Per Core Secrets leak, NSA/FBI both pay for and force backdoors in U.S. companies' products. They also share that information with other enforcement organizations per other leaks. Cloudfare are in a position to monitor lots of network activity. I'd be quie surprised if they weren't already backdoored.
If NSA/FBI aren't in one's threat profile, one might also be concerned about a court order over something having to do with copyright or patents. Damages for those can be huge. There's both legal and technical firms dedicated to pouring through data for evidence of patent infringements. Many licensing "agreements" start with evidence they find. I don't know much more about this. My wild guess is that they often start with tips from disgruntled workers or maybe those leaving for competitors.
These are main, three threats I'd be concerned about if sharing what I did with a U.S.-based provider. Double true for me given I'm in the jurisdiction of the enforcement agencies.
Let me be more specific: they might be fined out of existence and/or executives do prison time if they don't comply. They'll also be told to lie to preserve both the collection method and their businesses' success. Read the Lavabit case records to see FBI doing that. So, they'd be forced to comply and lie to you about it in that scenario. In such a scenario, faking transparency reports would support the lie and/or do some good showing they're stopping other threats. It's not all or nothing despite forced backdoors.
So, you basically have to believe the US-based company you trust won't take 8-9 digit bribe, will accept bankruptcy, and/or has people who will do time for your privacy. I don't trust anybody running for-profit companies to do that except for maybe Levison. Even he might change after weighing damage he received vs probably no benefit of principled stand. Maybe he'll stay in the fight, too. Who knows. I do know Cloudfare has financial incentives to take massive investments and/or avoid massive losses. Might work against users at some point.
To be clear, Im a big fan of Cloudfare. They're awesome. There's just upper limit of trust since they're profit-motivated operating in a quasi-police state (ie a Dual State).
"All of these involves cloudflare violating terms of service they've made to Mozilla."
Terms of service don't overrule federal law or court orders. That's assuming they'll turn down money. RSA told customers they were buying crypto with no mention of backdoors. Yet, they put one in for about $30 million.
So, a company might willingly violate ToS for a pile of cash or unwillingly do it via legal coercion that comes with secrecy order. Leaks indicated most took the bribes. Many more bribes or coercions might have happened since. So, we should just assume its true with companies in surveillance states with other security practices designed with that assumption baked in.
Also, it might not even matter if one isnt doing anything over those connections that's illegal. The backdoor becomes something probable but irrelevant for those users. From there, Cloudfare protdcts them from relevant-to-them threats like DDOS or delays causing lost sales.
Currently, the provider could read the SNI value from the request, but work is done to encrypt that as well. This would allow them to see which Hostnamen was requested, but they cannot peek into the actual transmission (which is incidentally how domain fronting works: announce a different SNI than the actual requests Host header)
> The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider. It’s not entirely working right now due to SNI being plaintext, but work is being done on that, too. So that’s really not a good argument.
If that was the whole point of https then we wouldn't have plaintext SNI. I can't even begin to understand why you think that there being a draft of an SNI encryption standard makes it 'really not a good argument'.
Originally, HTTPS required a dedicated IP address (or at least a dedicated IP/Port pair) for the server. SNI is a tack-on on TLS to fix that, so that TLS can be deployed more widely, allowing to encrypt traffic that was plaintext before. Encrypted SNI is a tack-on to fix that SNI needs to transmitted in plaintext. So yes, the design goal of HTTPS is to hide as much information from all intermediaries as possible. It’s just that you can’t fix everything at once, so gradual improvements are made.
Well, I can't get behind saying that hiding the site your visiting from your provider is the "whole point" of https when it specifically doesn't do that. I mean, we both understand what https is aiming to do in general, and I assume you aren't suggesting that https has been an complete failure since SNI was introduced.
However, admittedly I'm just reacting to you using the term "whole point" in conjunction with something it's failing to do.
I’m not suggesting https is a complete failure. I’m saying that HTTPS hasn’t yet achieved all that it intended to cover. It does the best it can given current real world constraints. That requires tradeoffs. But work is done to improve the situation and I’m generally happy for every feature that pushes the needle in the right direction.
So.. in some future Mozilla might select a default DNS provider on your behalf.
Did you consider the upside?
Mozilla can negotiate on your behalf. Mozilla can obtain favorable terms of service, concessions in privacy, third-party reviews. Things you would never be able to negotiate for.
If you think of Mozilla as negotiating on your behalf, they have motive to protect you, and they have the leverage to get concessions from 3rd party vendors.
Think of Mozilla as using the collective bargaining power of it's user-base to get favorable terms. This could be a game changer.
This replaces decentralised with centralised in the hope it would be a good idea if the choice is right. I'm sceptical, if nothing else because it would be easier to compromise or DoS one target than a lot of individual DNS providers.
> The article doesn't suggest there's something sneaky going on.
The article headline is "Mozilla's new DNS resolution is dangerous", so I guess you are right in saying they are not "suggesting", because they are down right accusing Mozilla of being sneaky.
edit: I have to point out that the article has backed away from the claim that this will be enabled by default in September. Looking at the Mozilla blog, they mention wanting to enable this by default but have no actual plan to do so (and more crucially doesn't discuss at all what sort of form it would have to be in for them to enable it by default, it may look nothing like the cloudflare-default we're discussing here).