F40 Change Proposal: Wifi MAC Randomization (System Wide)

Assign individual, stable MAC addresses for Wi-Fi connections

Wiki
Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

:link: Summary

Adopt stable-ssid as the default MAC address randomization mode for Wi-Fi networks in NetworkManager for Fedora 40, enhancing user privacy without compromising network stability.

:link: Owner

:link: Detailed Description

The change involves adding a new file, /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf. This file sets wifi.cloned-mac-address=”stable-ssid” as the default mode for MAC address randomization in Wi-Fi connections within NetworkManager for Fedora Linux 40. The stable-ssid mode, which generates a MAC address based on the network’s SSID, is aimed at enhancing user privacy. This new default value will apply to Wi-Fi profiles in Fedora Linux 40, but profiles have the option to explicitly set different values to override the default. The content of the added file is:

[connection.22-wifi-mac-addr] match-device=type:wifi wifi.cloned-mac-address=stable-ssid [.config] enable=nm-version-min:1.45

For further details, please refer to man NetworkManager.conf.

Note that this change will impact networks that rely on static MAC addresses. Users may need to adjust their Wi-Fi settings, particularly if their network operations depend on consistent MAC addresses. For example, networks with access control based on MAC addresses will need to explicitly set wifi.cloned-mac-address to “preserve” in network profiles to avoid any disruptions in connectivity.

:link: Benefit to Fedora

This change enhances user privacy by addressing the issue of MAC address tracking method used by network operators and advertisers to gather data about users’ movements and device usage patterns. By randomizing MAC addresses, Fedora reduces the potential for this type of passive surveillance, thereby enhancing individual privacy. It aligns Fedora with privacy-focused features present in other modern operating systems. The generated MAC address under the stable-ssid mode is derived from the network’s SSID, a per-host key (from /etc/machine-id and /var/lib/NetworkManager/secret_key), and a per-interface identifier.

:link: Scope

  • Proposal owners:

The merge request is already merged upstream.

  • Other developers: N/A

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

:link: Upgrade/compatibility impact

With the adoption of stable-ssid as the default in Fedora 40, existing users may experience changes in their Wi-Fi connection behavior, particularly those whose network setups depend on fixed MAC addresses. It’s crucial for users to be aware that upgrading to Fedora 40 will apply this new MAC address randomization by default. Users needing to maintain consistent MAC addresses for specific networks can address this by following one of these steps:

  1. Manually set wifi.cloned-mac-address to permanent for specific profiles using
nmcli connection modify [$PROFILE] wifi.cloned-mac-address permanent
  1. Create a custom configuration file in /etc/NetworkManager/conf.d/22-wifi-mac-addr.conf, which can be empty or contain specific configurations. This will prevent the default file in /usr/lib from being loaded.

  2. Create a higher priority .conf file like /etc/NetworkManager/conf.d/90-wifi-mac-addr.conf with:

[connection-90-wifi-mac-addr-conf] wifi.cloned-mac-address=permanent

For details on the order in which configuration files are loaded and their priority, refer to man NetworkManager.conf

:link: How To Test

  • Upgrade NetworkManager to version 1.45 or newer implementing the stable-ssid mode
  • Connect to Wi-Fi network using nmcli or the GNOME network settings
  • Use ip link show (replacing [device] with your Wi-Fi device’s name) to check the MAC address assigned to the device.
  • Note the MAC address and reconnect to the same network to confirm that the MAC address remains consistent across sessions.
  • Connect to different Wi-Fi networks and observe the MAC address for each connection.
  • Ensure that the MAC address is derived from the network’s SSID.
  • Manually override the MAC address for a specific Wi-Fi profile using nmcli connection modify [profile] wifi.cloned-mac-address [your-mac-address] to set a specific MAC address
  • Reconnect to the network and use nmcli device show [device] to verify that the specified MAC address is being used.

:link: User Experience

Users will experience an additional layer of privacy without any required action on their part. The change is transparent, with minimal impact on the day-to-day user experience. However, for those with specific network configurations reliant on static MAC addresses, this update may require manual adjustments to network profile settings. Users in such scenarios will need to be aware of the change and how to revert to a fixed MAC address if necessary, ensuring their network connectivity aligns with their requirements.

:link: Dependencies

N/A

:link: Contingency Plan

  • Contingency mechanism: Revert to previous MAC address handling if significant issues arise.
  • Contingency deadline: Beta freeze of Fedora 40.
  • Blocks release? No

:link: Documentation

No documentation change is required.

:link: Release Notes

The change will be mentioned in the Release Notes.

10 Likes

I’m not crazy about this. A common feature of home Wi-Fi routers is to pin a device’s DHCP address based on its MAC address. I use this feature on my home network and set a static DNS name for my laptops in the /etc/hosts files of my other home systems rather than relying on any sort of dynamic name discovery protocol (e.g. LLMNR). I suspect many home users do the same and this change would break all those systems until the users could figure out what has happened.

I know I’ve run into other things that didn’t work on Wi-Fi when MAC address randomization was enabled. But I’ve forgotten what they were. I think this change proposal has some possibility of causing some trouble for end users.

1 Like

I’m in favor of this change. I think for many users this would be a positive impact to user privacy without them having to do anything, which is a type of win that can be challenging to get in the privacy world. If I remember correctly, Apple implements randomized MAC addresses in their products. I don’t know if there are a lot of issues that result from them doing that, but I would assume that it’s not a big deal and people work around it if needed.

Judging by the example given, it seems like specific home configurations may require a stable MAC address. I’m not technical, but that seems like something that people go out of their way to set up and not the use case of most PC users who just want their computer to connect to WiFi. I think it’s fair to have a more private default that can be disabled by knowledgeable users who need something different from their device.

That being said, is there a way we can implement this update but not have it turned on for existing installs? If you’re upgrading from Fedora, nothing changes, but if you’re installing fresh you will get WiFi randomization by default.

Another point of compromise: can we require that documentation be prepare for the release so that users who need to set up a stable MAC address can do so with ease? This documentation can then be amplified by the Marketing Team via social media.

Personally, as someone who values privacy, I would love this feature to be on by default.

1 Like

As a regular user I upgrade because I want to be on par with the new features and improvements. I really don’t want to reinstall my system on each upgrade because of too many of these going around in the upgrade…

The proposal needs the step for enabling this feature after an upgrade please.

The correct format for the config file is in Changes/WifiMACRandomization - Fedora Project Wiki

It should be randomized with every connection, not just by network, similar to how GrapheneOS does it. This way you can’t be tracked on when you connect to a particular network.

That can potentially cause issues on regular use, specially when it comes to captive portals.

When it comes to this, it should be a balance between maximum security and maximum convenience, with the ideal world being reducing breakage to a point where it’s imperceptible to a regular user. Changing the randomization to stable only has a small potential of breakage in a small number of scenarios. Changing it to random would raise it to potentially noticeable in a lot more scenarios.

2 Likes

I am neither for or against this proposal the way it currently is, because I see it as a compromise with equally distributed advantages and disadvantages. However, I generally appreciate any increase in privacy, even if it can be weakened by “information gatherers”. Yet, I would prefer to add in anaconda or the subsequent user setup a button for the users to decide themselves: “Add MAC randomization” with a true/false button, and maybe a short explanation of the impact.

The problem I see: We have started to tailor and market Fedora for beginners without technical experience / non-advanced users. We even hide the terminal output on startup to spare them unnecessary input, and strongly simplified the setup.

Today such non-advanced users are able to manage their networks based on static MAC, and thus you can expect them to adjust the network settings if they have a new notebook because they are likely to be aware of the issue: new device means new settings in the network configuration.

However, if you change MAC on their operating system, non-advanced users might be not aware of WHY they can no longer use their network (from their perspective, the hardware/device is still the same) and thus they don’t know WHAT to do to repair it: It would take them only 5 minutes to adjust the settings, but it might take hours until non-advanced users find out WHAT the actual problem is and they may even give up before they find out. So I am not convinced that the average user of static-MAC-administrated configurations will be able to understand how to make their Fedora work again in the given network (I am not even convinced if every user can link “static MAC” to the means they use to determine which devices can enter which network service).

Also, be aware that some users might use static-MAC-administrated networks, which they do not administrate themselves. E.g., in many countries it has become normal that WiFI and such is included when renting a flat, and the landlords may use static MACs to mitigate abuse (I am aware that this security measure is easy to break, but it is still used in this way, and we might want to mitigate “denials of service” for our users).

The button in the setup would make them aware, and allow them to decide themselves if this makes sense for them.

So I would be +1 for adding the choice in the installation or the subsequent user setup, and maybe even to do it with opt out (thus setting the button by default to true) with a bold warning about the potential impact. Otherwise, I would be neutral / 0. In any case, I appreciate everything that takes care of privacy considerations and facilitates such discussions! :slight_smile: Thanks for putting it forward! :party:

2 Likes

Could you elaborate what such static-MAC-administrated network is exactly?

The effect of this Fedora 40 Change is that the device will begin using a different MAC address. From the perspective of the network, it appears as if a new device is joining. Most Wi-Fi networks permit the connection of new devices; otherwise, administrators and tech support would be rather busy.

For users unfamiliar with MAC addresses, the likelihood of them noticing the change is minimal. Users might observe they get assigned a new IP address and may need to login anew at some places. Note that the MAC address will be stable per SSID and is not regenerated on a regular basis. So this only happens once after moving to Fedora 40.

But no doubt, a few people will be affected by the change in a bad way, and will struggle to find the solution. I am sorry for inflicting such pain. But the vast majority won’t even notice.

To my understanding, also Windows, iPhone and Android do something similar (by default).

1 Like

I’ve been in hotels that charged an extra fee for using their Wi-Fi. They required the guest to sign in once initially and then their system allowed me to continue without having to re-authenticate for the remainder of my stay. Presumably, they were logging my device’s MAC address. I don’t remember if the fee varied depending on the number of devices (I only had one laptop). Hopefully not. Otherwise the person who applies this update while using such a network would get charged double.

1 Like

They wouldn’t because, even with stable, your MAC stays the same on the same network. What I was proposing would indeed affect this use case, but the original proposal basically makes Fedora work like every other mobile and desktop OS with market share. That hotel can’t possibly double-charge the majority of their customers. They would’ve received a lot of complaints otherwise.

2 Likes

It isn’t “stable” when this update is applied. Smartphones and tablets that have always had this setting would never change their MAC address for a given SSID. But what’s being proposed would. It would only happen once (per device), when the update is applied, but it would change the MAC address on existing network connections.

2 Likes

Home routers often have a feature to white list MAC addresses.
My last work place required that IT added my linux laptops MAC to their infra before I could use the network.

In both cases the feature is going to make these uses cases break.

1 Like

@glb mentioned a good example. I mentioned another one earlier with flats that are rent with WiFi, which is normal in some areas. Another example I know is university WiFis for employees and students, where the initial registration leads to the MAC of the device being registered (and at the worst the possible registrations being limited).

The major example I had in mind when reading the user experience issue is the most widespread router in Germany, which is shipped by most Internet Service Providers, in some cases by default, in some with a small extra charge (at first glance, I find statistics that mention it to have market shares from 50% to 70% in Germany, which sounds realistic to me):

This router has a simplified setup that offers normal users many settings to manage/control connected devices individually:
e.g., which device is allowed to access the Internet at all, which device is allowed to be online only in some time frames or online only for a given amount of hours, which device gets filtered by a whitelist, which one by a blacklist, or for young people: filter a device for problematic or pornographic content.

In all cases, admins might choose to avoid bypasses of these means by “implicit security”, which can mean that every device is filtered by whatever filter and only those that are explicitly excluded have unrestricted Internet access. I think a long time ago it was also possible to restrict admin access to specific devices (I don’t know if that possibility still exists).

I don’t use this device today myself, but I use it sometimes at a friend, and I know that it does not care if I use different operating systems with different host names if the MAC/network-adapter is the same: it treats them all as one device. However, if I change the MAC or the network-adapter, it assumes this is a new device (which had thus more restrictions). My expectation is thus that this is based on MAC addresses. Problem: Many users might not understand why this will no longer work, and because the router is designed for non-advanced users, the elaboration of the functions do not contain elaborations of MAC or such.

That’s indeed a good mitigation for new “registrations”. But it might not help with the existing registrations of the current MAC address. Again, the major problem in most cases is likely to be not to change the settings, but to become aware of the problem and thus where/what to check for a solution.

I agree that it is a compromise, and that it might cause a slight but existing advantage for the majority, and a very impactful disadvantage for a (very?) small amount of users. However, with regards to …

I am not sure how small the number of users with the disadvantage is, and if you are convinced, I would ask which data suggests this. I simply feel not able to predict this. I also do not know how many users of the mentioned router in Germany make use of such functions: even a 70% market share does not prove that any of these devices is used for that…

This is why I tend to suggest to let users decide. Also, I find it complementary and positive to include them in technical developments and decisions, and this is a decision that can be easily simplified in the setup to a level that any user could understand with a sentence or two. I like “demystifying” things for them whenever possible to also foster increased interest in the happenings on their computer. This is not an issue where the users need sophisticated knowledge to understand the impacts/interrelations. I think we should exploit that fact.

I don’t use any of them, so I don’t know for sure: is this the case? In all countries? This would indeed weaken my argument because I would expect that vendors of routers and such will respond to that. Nevertheless, I would first ensure that this is really the case everywhere.

1 Like

In my opinion, this is something that most users will blow past. When I install Fedora, there is a lot in the installer that I ignore because I don’t understand or it doesn’t relate to what I’m trying to do. I think that maybe encryption is one feature that fits with your suggestion, but even that I think will be glossed over by most users. In the end, I’m more interested in what will end up as the default option because that is what most users will end up with if we leave it up to them in the installer. When it comes to non-technical users, setting up privacy-respecting defaults is the best way to help they “adopt” a safer posture. It’s the kind of thing that users expect to not have to worry about.


On the question of the connections that will break if this change is approved, what would the fix be? Is it just a matter of logging back into the wifi?

3 Likes

The Wi-Fi that your devices no longer connect to because they are no longer whitelisted for access, yes. In vary rare cases (if the user only has one Fedora Linux laptop programmed for access to their router), it may be necessary to completely reset and reprogram the entire device to regain access. It will also be necessary to determine and re-whitelist the MAC addresses of your Fedora Linux devices. Depending on the router interface, it may require manually re-entering the 12-digit hexadecimal address for each Fedora Linux system you need to re-authorize. Also, the user needs to be aware that if they ever change the SSID (i.e. the network name) on their router, everything will break again and they will have to reprogram things again.

Edit: If they have a RJ-45 cable and their laptop also has such a port (or they own a USB adapter), the user could probably regain access to their router using the cable rather than having to reset it.

1 Like

I think the better way to solve the usability problem might be to have this option in GUI (e.g. GNOME Settings), like Windows and Android already do.

2 Likes

Is it feasible to keep the current MAC for already-registered SSIDs and randomize the MAC once for each new SSID only? That would solve many of the problems described above. The proportion of randomized MACs would increase slowly over time as machines and networks appear and disappear.

1 Like

You can customize the MAC policy in the connection profile settings:

  • GNOME Settings > Wi-Fi > Saved Networks > :gear: > Identity > Cloned Address > … > Apply

There’s a drop-down list of available options.

1 Like