Automate verification of Apple's new privacy labels

Developer Tips: What’s the deal with MAC addresses?

Published by Nathan Good on

AppCensus Hero Image

TL;DR

  • Don’t collect MAC addresses or use third parties that do:
    • There is no reason to collect the MAC address. Android’s documentation is unambiguous: “Don’t work with MAC addresses. MAC addresses are globally unique, not user-resettable, and survive factory resets.”
  • Don’t collect non-changeable unique identifiers—like MAC addresses!—for ad purposes:
    • Using these to track users for advertising purposes violates Google’s policies and can get you kicked off the platform!
    • It also violates your users’ trust by circumventing their privacy settings and may subject you to legal liability.
  • To check if your app is collecting MACs and other unique identifiers (UIDs):
    • Verify your code—including embedded third-party components (e.g., SDKs)—does not access MACs or other UIDs outside of official platform APIs or in violation of platform policies.
    • Regularly audit your app’s traffic:
      • Use mobile app privacy analysis tools, such as AppCensus, to inspect your app’s traffic. AppCensus is specifically designed to identify privacy violations—such as the inappropriate collection of MAC addresses—and provides a privacy-focused, deep analysis across the OS.
      • Existing free network traffic inspection tools (e.g., mitmproxy) can be helpful for inspecting some app traffic for the presence of identifiers. However, these tools are insufficient, as they are limited in their ability to capture and decrypt all traffic (e.g., such as transmissions that use certificate pinning, various obfuscations, or non-standard protocols), potentially missing identifiers or other illicit data transmissions.
  • Privacy compliance is an ongoing process:
    • Apps should be evaluated periodically for compliance.
    • Developers should be educated on platform privacy policies and privacy best practices.
    • Periodically assess and review your organization’s data collection processes to ensure they are not in conflict with platform policies and that they do not undermine user preferences and/or controls.

What’s the big deal with collecting a MAC address?

Over the past few years, we’ve seen many news articles that talk about apps’ access to MAC addresses, or other types of data that can uniquely identify users and their devices, such as the IMEI, Android ID, GPS location, etc.  But, what’s the big deal about this? And why should consumers care if they use an app that collects these identifiers? What is this actually doing to you and why does it matter?

As a developer, what are my responsibilities?

If you are a developer or app publisher, what is the big deal with accessing a unique identifier like a device’s MAC address anyhow? Also, if you are not collecting unique identifiers in your app, is it your responsibility to know every little thing the SDKs within your app are collecting (with or without your direction)? The answer is yes: even if you didn’t write the code within the SDKs that your app uses, they are still part of your app from both a legal and practical perspective, and therefore you’re responsible for their behavior within your app. If prohibited identifiers are being collected by SDKs within your app, you could be held liable.

What is a MAC anyway?

One way that apps can be privacy invasive is by uniquely identifying users’ devices (i.e., smartphones). Every device stores a set of numbers that uniquely identify it. Some of these a user can change, and some of these a user can’t change. For example, on Android, there is a unique ID, the Android Advertising ID (AAID), which allows advertisers to uniquely identify devices and then track their activities over time, in order to profile them for targeted advertising. (A similar advertising ID exists for Apple iOS devices, known as the Identifier for Advertisers [IDFA].) Consequently, because of privacy concerns around targeting and tracking, platforms give users an opportunity to reset or disable their advertising IDs. This is very similar to how web browsers allow privacy-conscious users to block or delete cookies. In other words, advertising IDs aren’t meant to be persistent.

Other IDs are tied to the hardware on the phone itself, and therefore cannot easily be changed by users. For example, all smartphones have hardware-based identifiers, which are used by the network interfaces when establishing network connections. When a user wants to connect to a WiFi hotspot, the phone shares its unique MAC address with the hotspot to facilitate the low-level inter-device communication required to establish a connection.

Early on, before advertising IDs were created, if a developer wanted to uniquely identify a device for any reason, they could rely on this more permanent type of identifier, as they were persistent, unique, and universal across all devices: they are bound to the hardware and set by the phone manufacturer! From a privacy perspective, this presented a problem for users: identifiers embedded in hardware are persistent (hard to reset) because they are needed for basic network communication, and therefore provide users with little control over how they are generated, accessed, or used. Since a mobile device is usually owned by a single person who carries that device with them all the time, identifying a device is nearly the same as identifying a person. And, when a person is identified, then everything they do on their device can potentially be tracked.

For this reason, unique device identifiers are considered sensitive and, in many cases, access to them is restricted by the phone’s operating system (or, even, hardware). Access to MAC addresses, in particular, are locked down increasingly at the platform and OS levels. In fact, since version 6 of Android, a developer is not supposed to have direct access to the device’s WiFi MAC address, which Google specifically states is for privacy protection. Starting in version 8, and by default in version 10, WiFi hotspots or routers don’t even get access to the unique device MAC address anymore; instead, MAC addresses shared with routers are dynamically generated and fluctuate. This MAC address randomization ensures that the original purpose of the MAC—allowing a device to connect to a network—works properly, while also mitigating privacy issues.

Why would an app still want to collect a MAC address?

Because the MAC address is designed in such a way that it’s unique, it allows phones, and by extension their users, to be uniquely identified. If a developer can get access to the MAC address, despite OS protections (e.g., by exploiting a security vulnerability), users can be tracked without regard for their privacy settings. When an app, SDK, or other third-party code illicitly gains access to the MAC, they are in effect denying user choice and agency by circumventing user controls, OS-level controls, and platform policies that are designed to empower users.

How are some developers able to access MACs with all these restrictions in place? The answer is by finding and using “side channels” to circumvent the controls and gain access. Side channels are loopholes that a developer discovers that allow them to access information that would otherwise be inaccessible. We’ve found and reported abuse of a variety of side-channels that allow access to device identifiers, and over the years platforms have made changes to the operating system to further restrict them. Nonetheless, they can still persist, and are especially an issue for earlier phones that aren’t running the most current versions of Android. 

Using side channels as a means to access the MAC address and other unique identifiers creates a host of privacy issues, which are clear violations of consumers’ privacy and often platform policies. For this reason, platforms strictly prohibit apps that exploit these channels, and will remove them from app markets when discovered.

  • For consumers, side channels effectively render many privacy controls ineffective.  What this means is that users who have “opted out” of tracking or reset their advertising IDs may still be tracked by third parties against their stated wishes.
  • For developers, exploiting a side channel is a clear violation of platform policies and can get your app suspended from the app store. Additionally, the circumvention of user controls may have legal consequences, including enforcement actions brought by regulators or other litigation.
  • The bottom line is that app developers are responsible for their apps, even if privacy-invasive behaviors are caused by third-party components (e.g., SDKs).

What can developers do?

Collecting device identifiers, specifically the MAC address, violates platform policies and may lead to legal issues. As a developer, what should you do?

  • Audit your code and data practices:
    • Inventory your data collection practices on your app, know what data you collect and how
    • Ensure that your development team complies with Google’s recommendations for the use of identifiers
    • Ensure that developers are not exploiting side-channels to bypass user controls and gain illicit access to protected identifiers
    • Review your code, permissions, and network traffic to verify that you are not collecting restricted data in violation of platform policies and applicable laws
  • Audit your third-party components and SDKs:
    • Verify that the third parties you use are not sending MAC addresses 
      • Traffic analysis using tools, such as mitmproxy, are useful for identifying some of the data sent by your app. (However, they may miss traffic sent via alternative protocols, such as UDP or QUIC, or traffic that’s encrypted using pinned certificates or bespoke obfuscations.)
      • Use a purpose-built privacy analysis tool, such as the AppCensus platform, to perform a comprehensive analysis of your app’s data collection practices 
  • Teach your developers about privacy:
    • Ensure developers review and understand platform data-collection policies
    • Ensure developers understand basic privacy engineering practices (check out future blog posts like this for guidance!)
  • Make privacy an integral part of your development process:
    • Regularly review SDKs’ data collection practices and other documentation
    • Regularly review the data-collection practices of your organization’s apps and components
Categories: Developer Tips