This has been an option in Android network settings forever: randomize your MAC. I think it's enabled by default now? It's a basic privacy feature; you can be fingerprinted by your device's MAC.

▲ jck a day ago | parent | next [-]

Yep. Android does this by default, but each ssid gets a randomized MAC which persists. It is still straightforward to trigger a MAC change manually tho. It is useful for privacy but imo useless for the public wifi limits use case since they almost always require an OTP via SMS to log in.

	▲	rahimnathwani a day ago \| parent \| next [-]
		`For devices running Android 11 or higher, users can enable non-persistent MAC randomization globally for all Wi-Fi networks (that have MAC randomization enabled) through the developer options screen. The option to enable non-persistent MAC randomization for all profiles is found at Settings > Developer Options > Wi-Fi non-persistent MAC randomization.`
	▲	matsemann a day ago \| parent \| prev \| next [-]
		Could you describe how? Quick searching doesn't show it to be "straightforward" as far as I can find.
	▲	tengwar2 21 hours ago \| parent \| prev \| next [-]
		OTP via SMS: depends on the country. These days it's not very common in the UK. They often ask for an email address, but my experience is that most of the time they don't check it for validity.
	▲	hhh a day ago \| parent \| prev [-]
		you have both options in ios/macos, fixed random mac per ssid, and rotating

▲ NoahZuniga a day ago | parent | prev | next [-]

No, this setting randomizes your MAC address between networks, but you keep the same MAC for a specific network. So if you want the network to think you're a new user, you'll need to change this specific network MAC address, and this isn't a setting enabled by default (and oftentimes is not even a setting)

▲

khimaros a day ago | parent [-]

GrapheneOS has per-connection (as an alternative to per-network) randomization which is enabled by default

	▲	rahimnathwani a day ago \| parent [-]
		Android 11 or later allows the choice in Developer Options.

▲ netsharc a day ago | parent | prev | next [-]

It's also in the Apple devices, you just have to "forget network" and reconnect for the device to tell the network of its new fake MAC address.

▲ alt227 a day ago | parent | prev [-]

How does that work with MAC address conflicts and clashes? I naively thought every MAC address had to be unique.

▲

BobbyTables2 a day ago | parent | next [-]

They must be unique in a LAN segment. And only the lower 3 bytes in a MAC are “unique” as the upper 3 are the vendor ID and relatively fixed.

In practice people put fewer than 256 devices on networks (class C), so they have less than 1/65536 possibility of complete failure. And far less because they have a mix of OUIs.

But yeah, if you put a few hundred or thousand security cameras or other device from a single vendor, all on the same network, conflicts are certainly possible.

MAC conflicts are also a bit nasty to troubleshoot, and less obvious than IP conflicts.

	▲	kazinator an hour ago \| parent [-]
		If your configuration doesn't randomize the MAC, that doesn't guarantee you won't be involved in a conflict. It only guarantees that it will go more badly for you, since you will be waiting on the other device to change their MAC before you get working networking. Whereas if yours is randomized, you will probably be okay after one reconnect. MAC randomization does not have to constrain itself to the lower three bytes; you can randomize the OUI too. What does Android MAC randomization do with the OUI? According to this possible hallucination from Google Gemini 2.5 Flash, the OUI is partially randomized too: - Locally Administered Bit (U/L bit): This bit (the 2nd LSB of the first octet) is forced to '1'. - Unicast/Multicast Bit (I/G bit): The least significant bit (LSB) of the first octet is usually set to '0' to indicate a unicast address. - Remaining OUI bits (and the entire lower three bytes): All the other bits in the MAC address, including the remaining bits of the first octet, the entire second and third octets (which are part of the OUI), and the entire last three octets, are randomized. Me again: So if two bits are fixed, everyone in the randomized space is randomizing 46 bits, which contains 7.03E+13 addresses. Practically speaking, it seems that the only way you will ever see a clash arising from the above randomization strategy is if two devices are using the same very poorly seeded PRNG.

▲

diggan a day ago | parent | prev [-]

There are like 50 trillion possible addresses, unlikely to clash in one network :)