From comments:
When we discovered this bug in iOS, we immediately tested it on an Android phone. Private Wi-Fi addresses are called “randomized MAC addresses” in Android world. We couldn’t spot the real MAC address in the network traffic that the Android device was sending during testing. It’s worth noting that this feature has been available since Android 8.0, which was released in 2017, as opposed to iOS 14, which was released in 2020.
I have a lot of issues with Android, but AOSP being source available lets you know if CVE’s are fixed instead of relying on the company to tell you the truth.
That’s for sure! I assume things like the goto fail bug would be found by the community pretty quickly.
The fallout for most iPhone and iPad users is likely to be minimal, if at all. But for people with strict privacy threat models, the failure of these devices to hide real MACs for three years could be a real problem,
Yeah, if you’re using an Apple product, you either don’t have a privacy threat model that needs it, or you don’t understand privacy.
This is the best summary I could come up with:
Three years ago, Apple introduced a privacy-enhancing feature that hid the Wi-Fi address of iPhones and iPads when they joined a network.
Enter CreepyDOL, a low-cost, distributed network of Wi-Fi sensors that stalks people as they move about neighborhoods or even entire cities.
In 2020, Apple released iOS 14 with a feature that, by default, hid Wi-Fi MACs when devices connected to a network.
Over time, Apple has enhanced the feature, for instance, by allowing users to assign a new private Wi-Fi address for a given SSID.
In fairness to Apple, the feature wasn’t useless, because it did prevent passive sniffing by devices such as the above-referended CreepyDOL.
But the failure to remove the real MAC from the port 5353/UDP still meant that anyone connected to a network could pull the unique identifier with no trouble.
The original article contains 680 words, the summary contains 136 words. Saved 80%. I’m a bot and I’m open source!
