Privacy risk associated with mac address

[Paul Theriault]

I have been thinking about what security & privacy risks are associated with allowing 3rd party apps to access the WiFi manager API. One property this API exposes is the MAC address of the wifi adapter. At first glance, exposing the MAC address would seem to be a very significant privacy risk because a) its guaranteed to be globally unique, and b) the user has no easy way to change or cycle this identifier. Currently the API is certified only (only Mozilla and partner apps can get access to this API) but there is a desire to open this up for various legitimate use cases (improved geolocation accuracy via wifi scanning for example).

How important is it to never allow disclosure of the MAC address to 3rd party apps ? Am I overlooking other factors which mean the work in restricting access to the MAC is not such a valuable control ?

To me it's similar to [1] which currently is an Implicit Privileged permission [2]. However in that case you can always eat your SIM card if you worried that They are on to you.

-Paul

[1] https://developer.mozilla.org/en-US/docs/Web/API/MozMobileNetworkInfo
[2] This means only apps reviewed by Mozilla Marketplace can get this permission, but users are not prompted before an app can read this.

[Florian Bender]

On Monday, November 4, 2013 3:24:57 AM UTC+1, Paul Theriault wrote:
> I have been thinking about what security & privacy risks are associated with allowing 3rd party apps to access the WiFi manager API. One property this API exposes is the MAC address of the wifi adapter. At first glance, exposing the MAC address would seem to be a very significant privacy risk because a) its guaranteed to be globally unique, and b) the user has no easy way to change or cycle this identifier. Currently the API is certified only (only Mozilla and partner apps can get access to this API) but there is a desire to open this up for various legitimate use cases (improved geolocation accuracy via wifi scanning for example).

Simple solution:
A) Change the spec to allow passing arbitrary MACs for API users of lower privilege. I.e. certified apps get the real MAC while all others get a MAC of "0x0" (or random MAC per App which allows the OS to "spoof" MACs regarding the App).
B) Change the property to a getter which may fail. I.e. return the MAC for certified apps and throw/return false for lower privileged apps. Technically, this is not very different to (A), but:

(B) requires code changes, wheres (A) does not (but may confuse devs).

I'm all in favor for not exposing any identifiable data. Even Apple restricted access to system-wide unique IDs (though they may provide app-specific unique IDs, which (A) may also provide if it returns a random, tied-to-origin-URL MAC instead of "0x0" – however that use case is better solved with a dedicated API, I guess).

[Gervase Markham]

On 04/11/13 02:24, Paul Theriault wrote:
> I have been thinking about what security & privacy risks are
> associated with allowing 3rd party apps to access the WiFi manager
> API. One property this API exposes is the MAC address of the wifi
> adapter. At first glance, exposing the MAC address would seem to be a
> very significant privacy risk because a) its guaranteed to be
> globally unique, and b) the user has no easy way to change or cycle
> this identifier. Currently the API is certified only (only Mozilla
> and partner apps can get access to this API) but there is a desire to
> open this up for various legitimate use cases (improved geolocation
> accuracy via wifi scanning for example).
>
> How important is it to never allow disclosure of the MAC address to
> 3rd party apps ? Am I overlooking other factors which mean the work
> in restricting access to the MAC is not such a valuable control ?

I think (although I don't know whether it's actually so) that we should
prevent ordinary apps getting any sort of unique identifier for the
device - MAC address, IMEI, phone number. So yes, exposing the MAC would
be bad.

The other place which knows your Mac is the very first router that you
connect to over the Internet - but ideally, that would be trusted, or at
least not running active "reflection" services under the control of an
attacker.

Gerv