Apple, Google and the MAC address randomization

High-wire act user comfort vs. privacy

As already reported, with the rollout of iOS 14 – in all probability from mid-September – there will be a challenge for all networks using the unique MAC address of a device for authentication in order to only allow data packets from such authenticated clients. In previous beta versions, MAC address randomization was preset every 24 hours, and all signs indicate that this will also be retained in the actual rollout of the update.

As a reminder: There have been the first developments in this direction since the early 2010s. In fact, the unique MAC address, which is already assigned when a network-compatible device is manufactured – comparable to a license plate or a serial number, for example – enables the device in question to be uniquely identified worldwide. In all Ethernet networks it would be problematic if, for example, a Layer 2 device address were to occur twice, and this can be clearly ruled out by this method.

However, what ensures smooth functioning for the intended operation of a network can – like so much in technology – also be used for unfair purposes. If, for example, the MAC address of a certain system is known, it would be possible for an attacker to draw conclusions about the user and his activities and to collect data, for example to search for data packets sent in a specific period and compare them with other periods.

Hiding the MAC address is therefore a feature for better data protection and is called “Data protection – use random MAC address” on Google and “Private network address” on the iPhone, with an explanation that the use of this feature prevents tracking.

This claim is definitely worth questioning: There are not only other tracking methods, but also ways to force a smartphone to reveal the device MAC address, so the added security is not totally outstanding. Accordingly, both manufacturers have given thought to not having a disproportionate impact on user comfort. A hotel guest, for example, who appears in the guest directory with his or her personal data, has to expect more comfort than danger when a network operator knows of his presence. He probably doesn’t want to log into the WiFi every day. The same applies to patients in clinics, students and teachers on their campus and employees on company premises or in their own home network.

Correspondingly, Android decided to hide the MAC address for each SSID – i.e. not to display the device address, but to keep the pretended address for each network SSID. This avoids experiences that impair user comfort with little gain in security.

This is different with Apple, where – as it has been the case up to now – randomization takes place every 24 hours. The randomization should supposedly not work for networks that have already been saved. How the iPhones from version 6, which will presumably all receive this active preset, ultimately behave, will only be seen in practice in autumn / winter. But we must at least be prepared to receive support inquiries because iPhone users have to log in every day.

Apple support pages already describe how this behavior can be deactivated, because it is easy to foresee that users will find this impractical in regularly used networks. For each stored network, you can decide whether a randomized or the real MAC address of the device should be used: https://support.apple.com/en-gb/HT211227

Anyone who now feels reminded of the early 2010s is not wrong. The subject of MAC address obfuscation was already present in the specialist press with iOS 8. And the Hotspot 2.0 standard of the WiFi Alliance, which was announced back then as the “beautiful new hotspot world” with seamless connectivity experience, is making people hear again.

Hotspot 2.0 (HS2) / Passpoint as the standard of the WiFi Alliance was and is often touted as a solution for seamless connectivity, but was originally conceived for carriers / cell phone providers and not for operators who offer their customers added value in the form of guest WiFi and a consider it a customer touchpoint. The use case of a guest who comes to a hotel without a regionally valid mobile phone contract (like the long-distance traveler) did not even occur in the scenarios at that time.

In addition, the technology only works if the hardware supports it. US-heavy manufacturers in particular have Passpoint-capable hardware in their product range, but even that is not always available through the entire product line, and so implementation can be difficult depending on the environment: Access points must be HS2 Passpoints, i.e. they must acquire or have acquired certification from the WiFi Alliance. Even with well-known manufacturers, this is often only possible in conjunction with the WLAN controller. The technology also requires support on the client side, which is also not available on all current smartphones.

What does this mean for IACBOX operators?

Since we at Asteas know all too well how different the landscape of the IACBOX operators is out there in the field, we as a manufacturer prepare for all eventualities.

The IACBOX will therefore support the Hotspot 2.0 standard, so that everyone for whom it makes sense to set up the network accordingly can count on their usual portal.

But we also want to provide the best possible care for all those who consider this to be too costly or tiresome for their respective application, by …

• … sharing information on how to do without this standard, as we have some customers who will shy away from the effort. This requires the participation of the IACBOX partners and end customers in the communication to the end user (guest), and we will work together on the communication as best as possible. Also …
• … providing a pop-up for the login page that explains the situation to iPhone users among the guests in the WiFi network. That should significantly reduce the number of queries at reception and support.

Ultimately, it is the guest himself who has to decide whether he would like to log in again every day or whether he would like to deactivate the randomization in the respective network where he is currently located.