An instruction like that is why I don't use Linux as a desktop!
This has nothing to do with the linux desktop - this is a misconfiguration of the dhcp server, which would affect all clients. The mac circumvented the issue because it sends out information of all previous networks (which is a security issue, btw - I'd rather not want my laptop to push out all of my recent networks' information to anybody).
Also, this guy is running his own ISC dhcpd server to have more control over the network and to learn more about networking in general. This is not a professional network admin/dev - of course he doesn't do all of it right, but if he'd read the manual, he would've enabled it. Seriously, even in default configurations the option is marked as 'if this is the only DHCP server in the network you'll want to enable this' or something along the lines of that.
So we're not speaking about an out-of-the-box ready-to-roll router - we're talking about a guy who's running a server with Ubuntu on it to provide leases to his network.
Besides - the same would've happened if a windows user were to use Microsoft's DHCP server, which is non-authoritative by default as well. It's a good practice that a DHCP server on default configuration doesn't assume to have the authority - since, well, since the configuration has not been touched.
It's some information about the last few _wired_ networks you've connected to, to any of those networks, that the owners of those networks already have. If you have a wifi you already know which network you're on, and there's no sense in asking about addresses you haven't seen with that SSID+key.
There certainly appears to be a privacy issue if you're connecting to a lot of public ethernets and those sites (can) collude, however if those sites can and do work together, they can unmask you anyway.
If they don't yet collude (but are willing) and you don't use random MAC addresses, then there may be another privacy issue where they can use the MAC address you leak to discover each-other, but I'm unconvinced even Google has the resources to do this.
How often do you find yourself needing to run a DHCP daemon on your desktop, Linux or otherwise?
Some might say that Windows' DHCP setup being authoritative by default is one of the reasons they prefer Linux on the server. It is not the safest default: sending NAKs when you shouldn't could cause significant disruption, not sending NAKs when you could correctly do so does nothing worse than delaying new connections by a few seconds.
But its a dhcp server, network admins would be expected to touch config files, and the interface for a DHCP server really can't be much worse than the GUI version that microsoft supplies!
but digressions, to say "this is why I won't use a linux desktop" in response to a server-specific use-case, is at best antagonistic!
Conversely, most group policies I have ever needed were pointed out, including where to find them, after one web search, and their use is extensively documented in the config editor.
> were pointed out, including where to find them, after one web search,
Well, if you are doing that one web search, it doesn't matter whether the named key is for gui or text config. Except for that localization issue, if you find English string, it won't help you with localized one.
Then there is the issue of the GP items themselves: many times you don't know whether to choose enable or disable, because double negatives FTW.
There are still some configuration items that have to be set in the registry or through Powershell (wmi and so on). The registry is much worse than editing files in /etc/ because you can't back it up, revision control it, or put comments in.
Random googling reveals people having surprisingly similar problems with the Windows DHCP server: https://community.spiceworks.com/topic/332253-cannot-backup-...
As for GNU/Linux, I know it since Slackware 2.0.
Leaving aside the fact that the variation among Windows versions is quite small versus the GNU/Linux distribution fragmentation.
Making it authoritative is then to just press a button in that dialog.
Yes. You have to know that you have to open the GUI for DHCP server configuration in order to configure the DHCP server, but that's really all you need to know to prevent the issue described here.
isc-dhcpd that's often used under linux doesn't even warn to syslog when it's not authoritative. All indication for doing so is given in the sample config file using
# network, the authoritative directive should be uncommented.
#authoritative;
Case in point: Back when I was learning about all of this my Windows-based DHCP servers were all authoritative, whereas none of my Linux or FreeBSD based DHCP servers were.
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
Though for the opening to the current discussion that is a moot point - this is not relevant to either OS on the desktop.
Seriously, I understand where you're coming from, but you're blathering needlessly about an issue that is a) not really a contentious one, and b) completely irrelevant to the discussion.