My ISP allows 2 MAC address to get IP addresses con-currently from their DHCP via their Ethernet link.
If my MAC address is changing (due to frequent reboot while testing someting) faster than their DHCP expiry time, then I will got be able to get a new IP.
That is a matter of how it is presented and with which information. The encrypt button is indeed one that can easily be overseen, although the term encryption is already a trigger for many people, and we have a lot of users without sophisticated knowledge who use it (based on what I saw in ask.fp over time). But yes, I am quite sure that a lot of users who might profit from it will overlook the encryption possibility. Also, I agree that me might be careful with the amount of stuff we put in the installer and remain selective.
They have to worry about a denial of service if they can no longer use some networks, without knowing what the problem is or where to look for solutions. I am not sure that MAC randomization is a āone size fits allā thing. Also, the privacy that is preserved is limited because the primary āinformation gathering meansā for getting user information are on higher layers.
You assume that users will be able to immediately understand the origin of the problem and thus know where to look for a solution. I doubt that this will apply in all cases. I refer here primarily to the examples in #15. However, there might also be alternatives to my suggestion of the installer / user-setup in terms of when/where to let users know what impact can happen and what they could do about it.
However, I read in the mailing list that there is a RFC that seems to be implemented by the ābig threeā: Microsoft, Mac, Android. So, most users will experience the issue anyway, and if so, there will be likely a lot of help pages that elaborate the issue and thus indicate what/where to look for. Also, it makes me think that vendors of, e.g., home routers and such, will consider the issue and find some mitigations for users.
I am generally not in favor of introducing this, but I think that keeping consistency among the systems is helpful, and it might be a small but existing mitigation to introduce this measure on all systems roughly at the same time. Then users might ātransferā that it is the same everywhere or remember that they have experienced the same recently in their Windows or such.
If this RFC develops towards the de facto standard, I tend to be +1 to adopt it, to keep consistency and exploit support pages/measures for Windows/Mac/Android, even if I am a scepetics of the measure itself.
However, in case this will be introduced, what do you think of adjusting the starting page of Firefox on F40 to contain a hint of what they might experience and how to respond (especially if we also provide a GUI button)?
Most users tend to first check their Internet (and related issues) by opening their default browser and check if it works or if they can use their preferred search engine to search a solution:
A small bold warning (and maybe a picture or two of how the problem manifests - e.g., the limited connectivity warning - to capture their attention) with a hint and a few pictures of which button to pull to disable the MAC randomization if they are affected negatively could be a good mitigation without increasing the stuff in the installer.
IMO, the āMAC randomization will break my WiFi whitelisted connectivityā is not an issue: any user which were able to configure their router WiFi whitelist will have the knowledge and the skills to understand this change and adapt their configurations. Any user which canāt understand what MAC randomization is about surely havenāt set up any whitelist on their router (or they have someone else who manage their network and most probably takes care of upgrading their OS).
I can see this becoming a FAQ that we deal with here when supporting folks.
That is not to say donāt do the change, but it would help having a how to turn it off web page we can point people to.
Is this with the new stable-ssid option in the upcoming NetworkManager 1.45? So far, Iāve only tested restarting NetworkManager and the MAC address was consistent for the same SSID. But I may have to test rebooting. But it shouldnāt change because thatās for the random option.
Im quite sure thatās false. The router that has a market share between 50 and 70% in Germany (and I think also a noteworthy market share in Europe) and which I elaborated above is so successful because it offers such functions in a way every user without related knowledge can use them. It allows them to easily setup profiles (whitelist profile, blacklist profile, guest profile, https-only profile, child profile that filters obnoxious content, and so on) and then link any computer to any profile, and to set a default profile, but potentially also to enable that only some profiles are allowed to enter admin interfaces. Also, there are wizards when they setup the routers to make them aware of the easy-to-use possibilities and manuals for beginners (some examples can be found here and here). As elaborated above, there is indication that this is realized using MAC addresses.
The problem is that the user interfaces are intended for average users and thus elaborate things in a very simple easy-to-understand-way - this means there is no elaboration or link to āMACā or so. And that makes it hard for average people to link potential issues they experience to these functions (if they are able to link it to their router at all)ā¦
The same applies to people who use services that are administered by others. We elaborated sufficient examples of that above, too.
But again, if everyone implements this RFC, I assume the vendors will ensure some mitigation. And even a market share of 70% would not imply that any device is using these functions. But we should avoid hasty assumptions.
Actually, iOS does randomize your MAC again by default if you donāt connect to a network after a few weeks. And I doubt there would by many who will upgrade to Fedora 40 while on their hotel stay. As for networks with whitelists, if they set it up for themselves the first time, theyād already know how to set it up again. And if it was done by an administrator, then they can ask them to set it up once more. (Think of it like resetting or buying a new phone). The only problem here is notifiying them about it, but thatās what the patch notes and Fedora Magazine are for.
Are you talking about the effects of the initial update or how it will work generally? If itās the latter, than itās no different than your other devices because the address doesnāt actually change for the same WIFI. And even in the former case, itās no different than adding a new device you reset or bought. Surely that router mustāve accounted for buying new phones. Also, as I said above, iOS automatically randomizes it after a few weeks without use. A quick search shows me that iOS has an 18% market share (and 38% on mobiles). Iām sure that that router have also accounted for such a large number of users, say, coming back from a long vacation. Then fedora should put in the version page something like āif you havenāt set a mac address, the new default will initially randomize itā to let everyone know.
I was referring to existing networks/configurations/connections that will no longer work after the randomization. E.g., a user without much knowledge has setup his router earlier (through the simple wizard web interface and the manuals written for average users without technical elaborations) to filter obnoxious content and to whitelist all devices by default, and only allow unrestricted access to devices that are explicitly set to a profile that is unrestricted. If the MAC then changes, no machine might be able to have unrestricted access anymore, and the user who has no knowledge of the issues and does not know of technical backgrounds/interrelations and impacts will have neither an idea how to solve that issue nor where or in which GUI to look for solutions. That was a āmajor exampleā I had in mind.
I think we are on the same page in this respect. See:
Indeed, this is more or less exactly the same. But thatās still the issue I meant: people who setup such configurations will know when they buy a new phone, but they will not know that this is the same implication:
Yes, it can be set manually, but I was referring to the behaviour of this proposed change. If the randomization default were applied only to new profiles, it would resolve many of the issues raised, while eventually achieving virtually complete adoption.
I donāt see why not. Iāve made a simple bash script[1] that sets the cloned mac address to permanent, the previous default, to wifi networks that donāt have one set already. If you run it, the new change would effectively apply to new wifi networks only.
[1] https://gist.github.com/o-kotb/59f02fc4de8fea54837333becbb78167
It does feel like it should be possible to do this in a way that doesnāt trigger this scenario:
Itās only existing network configurations that have the potential to be so negatively impacted by this change ā if someone joins a new network, after this change is applied, their profile gets created with the randomized address, which is the only address their machine has ever had on that network. Itās compatible with all MAC-based access controls and etc.
But for users with existing network profiles, flipping a switch that does even a one-time randomization of their already-established MAC for a given networkā¦ feels like it might do more harm than good.
So, couldnāt we fix things so that all existing network profiles get āgrandfathered outā of this feature? Even if it means having to ship a NetworkManager update to F39 that adds the opt-out config to all existing profiles, before F40 then changes to the new default for new profiles created after that point.
Any grandfathered-out users who wish to activate randomization for their existing configs could be provided with information on how to do that. (One option would presumably be to just delete their existing network profile and create a new one, which would then receive the new default randomization setting.)
BTW, for @till , is the opt-out configuration āpreserveā or āpermanentā? It seems like itās both ways, in the doc:
ā¦Or are those two different settings, appropriate for different scenarios?
Thank you for noticing this. The best choice seems to be permanent. I updated the wiki page.
This change proposal has now been submitted to FESCo with ticket #3136 for voting.
To find out more, please visit our Changes Policy documentation.
So, low interest in gradual adoption by default, then? Those attentive and savvy enough to understand they need to opt out can do so, and the rest of the affected users can just deal with a one-time connectivity loss surprise?
Note that this is my first time participating in a Fedora discussion, so my idea of adequate user experience might not be well-aligned with that of Fedora.
That is something you cannot count on.
Alright, Iām not against gradual adoption. If somehow that script can be run in the upgrade process, itād probably solve all problems. But Iām also not in FESCo. But even full immediate adoption is still much better than the current setting, IMO.
There seem to be a lot of conditions that need to apply so this will become an actual issue for a user:
This reduces the amount of possibly affected users very much. Therefore it seems to be reasonable to do this change.
It seems to be it would be nice to have some troubleshooting pop-up/help on the desktop in case connecting to a network does not work anymore which could mention this. However, this is something we donāt have the capacity to implement.
By the way, if a userās laptop breaks and they get a new one, they would also need to handle the changed MAC address somehow.
We had that point before, but you have to consider that the users might be aware of the rough issue (and what to do) when the notebook breaks or if it gets replaced (new machine = new adjustment), but they might have no idea what is going on or what to do / where to check if the MAC is just changed without their knowledge ā they might have no idea why something no longer works or how to identify what exactly is broken and thus have no idea what to do / whom to ask:
If I got it right, you are from Germany: I assume you know the Fritz!Box. You might check what they make possible for average users without much knowledge - with their easy interfaces, users handle their networks with MAC addresses without noticing any technical background. They are aware that they are handling machines and thus, changed machine = adjustments in the Fritz!Box. But if we do that change on the very same machine, they might have no idea where to look for the problem. I elaborated that example in #26.
Donāt get me wrong: if that is already the standard at Android, Mac, Windows, and if they all do it in a compatible/comparable way, I am +1 to do that as well ā to keep things aligned, behave the same way, and āde factoā standardized, even if the RFC is not yet an official standard. I have no doubts that if all major systems do it, the vendors of widespread hardware will respond correspondingly (maybe they have already).
But as long as we market Fedora as a system for beginners and average users, the argument that ānew computerā is equal to ājust a changed MAC without the user being explicitly informedā is not tenable: for people without knowledge of the underlying technology, this is a big difference, and one of the two cases might disable them, while in the other case their superficial knowledge in combination with the simplified Fritz!Box interfaces/manuals (such as the mentioned examples) made them aware how to respond, and when to consider what. Obviously, the Fritz!Box is only one example.
