How Google can fix the Marshmallow MAC Mess and enable P2P apps

Google in Android release Marshmallow prevents applications from seeing their device’s local Bluetooth or WiFi MAC addresses. This puts a big roadblock in front of peer to peer apps. There is a really obvious solution which I suspect Google has thought about, so now the question is - why haven’t they implemented it? Does anyone have a contact at Google I can talk to about this?

The problem

See here for the gory details but the upshot is that for security reasons Google doesn’t want apps able to figure out what their local MAC addresses are. My understanding is that the motivation is to prevent apps from using these addresses to track user’s locations. If that were true however then why, when the user explicitly gives permission to the app to know their local location, isn’t the MAC address available to the app?
The only theory I can come up with is that if a user removes the app from the phone, Google doesn’t want to have leaked to the app information that could be used to continue to track the user in the future. In other words, imagine a user installs BadApp and gives it permission to know the user’s location. Now imagine that this gave BadApp the user’s Bluetooth or Wi-Fi MAC address. Later on the user figures out that BadApp is bad and removes it. But it’s too late, the permanent MAC has been leaked and the device can be tracked.
So this argues that it’s best, if possible, not to ever leak the MAC to apps.
The problem is that P2P apps that want to use Bluetooth are collateral damage from this approach. BLE is too slow and Wi-Fi Direct has a broken UX and doesn’t work right. So P2P apps are left with Bluetooth. But as the previously linked article explains, Bluetooth discovery is not amenable to P2P scenarios.
There are, however, a couple of obvious solutions.

Solution #1 - Make Wi-Fi Direct work and get rid of the user permission dialog

For Thali, Wi-Fi Direct was dead on arrival. To enable two devices to communicate over Wi-Fi Direct there is a user permission dialog required by the OS. This is required by the Wi-Fi Direct standard and has literally no useful security purpose given all the other ways that apps can communicate. It’s just a pain and it needs to go.
But even if that were fixed I still suspect Wi-Fi Direct would be a problem. Just using Wi-Fi Direct has caused us all sorts of awful problems including making the main Wi-Fi AP connection lose it’s mind even when we aren’t sending anything. So it’s not enough to get rid of the permission dialog, some seriously heavyweight interop testing would be necessary to get to the point where one could reasonably expect Wi-Fi Direct to work properly across devices from random manufacturers.

Solution #2 - Allow users to create Bluetooth Devices with random MACs

In theory the Wi-Fi Direct solution is my preferred solution mostly because of Bandwidth and range. Bluetooth is 10x slower than the slowest Wi-Fi connection. Wi-Fi also deals better with contention and in the real world may have longer range. But given all the interop issues I’m not holding my breath. So my hope is that Google will go for the solution in this section, which is to treat Bluetooth like BLE.
When creating a BLE peripheral in Android the app is given a new BLE MAC address that is only used by that app. So if a device has two BLE peripherals running on it then the device will listen for two different MAC addresses. Google already does something like this on Bluetooth and WiFi with its new feature that when scanning for Bluetooth/WiFi devices a randomized MAC is used. So if Google expanded this randomized MAC support to creating dynamic Bluetooth listeners then it would be fine for the app to learn the randomized MAC address.
The reason sharing the randomized MAC address is fine is that if the app is ever removed from the device then its Bluetooth listener will be removed too and along with it the randomized MAC address. And yes, Google can mandate that only apps with permission to know a user’s location can generate new Bluetooth listeners with randomly generated MAC addresses.
Approached this way Google gets all the privacy it was trying to provide and P2P apps can continue to function thus providing users with even more privacy.

Conclusion

For now we are putting a big stumbling block in front of our users by having to implement Bro Mode. This is an awful and confusing user experience that just pushes apps to send everything to central servers instead of providing users with much better privacy and security by using local P2P connections when possible. So if privacy is the goal we should be looking to empower P2P. As explained above enabling P2P doesn’t mean having to reduce privacy in other areas. Furthermore the second workaround is clearly doable without Herculean effort, if Google has the will.

Leave a Reply

Your email address will not be published. Required fields are marked *