3 ms·
The author may have the systemd-resolved privacy complaints in mind, where the systemd DNS daemon has Google's DNS servers hardbaked into the source code. It wi
by HeckFeck 6y ago
The author may have the systemd-resolved privacy complaints in mind, where the systemd DNS daemon has Google's DNS servers hardbaked into the source code. It will fallback to Google DNS if the configured server is down.
A few concerned individuals raised their worries in a ticket and were shut down for 'tinfoil hat reasoning' or something like that.
It may be an extreme case, but many Linux users would rather not have any particular provider baked into core system services. Personally I'd rather know my DNS server is down or that I've misconfigured it, much more than I would have my system contact Google without my knowledge.
Src: https://github.com/systemd/systemd/blob/41c81c4a626fda0969fc09ddeb8addb7aae6e4d9/meson_options.txt#L221 https://github.com/systemd/systemd/blob/41c81c4a626fda0969fc...
- oytis 6y agoI mean. It's an open-source software. Those concerned can just use a patched version. Not even patched - this is fixed with a build flag - I'm sure security-oriented distributions have already specified the right one. As a last resort, you can always block requests to 8.8.8.8 with iptables.
- Datagenerator 6y agoNo need for firewall configuration, just: ip route add blackhole 8.8.8.8
- sverhagen 6y agoThose concerned may be as much or more concerned about fixing this for the masses as they are about fixing it for themselves, hard to speculate on their motivations.
- josefx 6y agoI would be more interested how much systemd made from selling its users tracking data to Google and if they didn't it would be interesting which idiot passed up a chance to secure a possibly sizeable budget increase by handing Google all that data for free. Mozilla got millions from making Google the default search and you can't tell me Google doesn't value the data it gathers from this, they have a tendency to kill under performing projects.
- oytis 6y agoIt's still not a reason to harrass a maintainer who already provided a convenient override to set it to whatever one wants. Maybe Ubuntu distro is a better place to get the "safe" configuration to the masses. It's a pretty rare phobia to be honest, and I think people who consider 8.8.8.8 a reasonable default are totally justified to. For those who don't agree there are plenty of options, that's how open source is supposed to work.
- e2le 6y agoWhile it's possible for it to be patched out, the default behaviour of any application with similar scope to systemd should be to respect the users privacy. If every application required the user to "opt-out" of privacy infringing features, it would be a very time consuming and costly activity that only knowledgable users could do.
- oytis 6y agoRegular users are likely to spend most of digital lives on a device fully controlled by Google, I doubt that a couple of requests to 8.8.8.8 will be a significant compromise to their privacy (how do they know that whatever they get from their provider is better by the way?). My main point here is just that open source maintainers don't owe humanity anything - they already gave it a lot of their time. If people strongly disagree with some design decisions - and it's not a backdoor or something, it's a pretty innocent design decision to rely on a highly available DNS server as a last back up - open source gives them a lot of opportunities to do their own thing.
- e2le 6y agoUnfortunately I don't find your argument to be convincing, the knowledge of such privacy concerns varies significantly amongst regular users. I don't believe they are using such software with full knowledge of their privacy-infringing features. And with every feature that evolves such default behaviour, it risks snowballing into rituals that must be performed in order to "opt-out" and done only by those knowledgeable enough. > I doubt that a couple of requests to 8.8.8.8 will be a significant compromise to their privacy It could be, it could be more. I don't think either of us are in a position to say exactly and likely largely depends on whether such default behaviour was changed by package maintainers in the various distributions. > My main point here is just that open source maintainers don't owe humanity anything - they already gave it a lot of their time. This is something we both can agree on however I tend to apply this only to those not receiving a salary for doing OSS work. I am of course not endorsing harassment or anything of the sort. People should always choose respectful conversation and debate when discussing these issues.
- eecc 6y agoAlso NTP points to Google’s servers
- e2le 6y agoHere is the rationale for using Google as the default for ntp which appears to be a problem with ntppool.org than any supposed favouritism for Google. https://github.com/systemd/systemd/issues/16148 https://github.com/systemd/systemd/issues/16148 However I was under the impression an OSS project could use *.pool.ntp.org as their default but was preferred that they get a vendor zone. https://www.ntppool.org/en/vendors.html https://www.ntppool.org/en/vendors.html
- birktj 6y agoThe page linked says "space-separated list of default DNS servers". From this I would assume that this is just an option one could simply overwrite by using a non-default configuration. That doesn't seem so bad, however I could also be misunderstanding and in order to disable these servers one would need to patch the source code like you imply. Do you have a more specific source that would answer this question? Edit: from the other comments in this thread it seems like it it is a build time option
- marcosdumay 6y agoIt's a hard-coded (as you found, compile time macro) value that resolvd uses when it can't find any configuration. So, one doesn't need to patch the source or recompile resolvd, one just needs to add a configuration file (what most distros do). That said, it's mind-blowing that systemd needs a DNS resolver to start its boot sequence. It should really be able to run without one, and have this as the default. It should also not try to set the network up before it runs the network setup code, and respect all of the user's network configurations. The entire thing is completely messed up, but this one complaint isn't all that it looks like.