Meraki Location API Vs Android 10 Mac Randomisation

[WFS-Matthew]

Since the release of Android 10 (Android Q), they have announced their new default mac randomisation settings, which based on my understanding, does the following:

• Random mac (probably outside of the OUI) per SSID (Saved in to a profile)
• Never using the hardware mac address unless the user allows it to (such as manually overriding the default for your home network)
• All associations and connected traffic will never use the actual mac address

Because of the above, how will the Location API handle things? If the device becomes unidentifiable, and is forever changing the mac address, won't this begin to impact the dashboard analytics when trying to understand visitors and passersby? I know mac randomisation has been a thing for a while but it's been poorly implemented so far making WiFi scanning really effective.

Right now it isn't a massive issue because the OS hasn't been out for long but if this is the way things are going, I'm struggling to understand how much further use the Location API will have, especially if Apple decide to follow in Google's footsteps.

[BrechtSchamp]

I think in the long run it'll become impossible to do this based on just Wi-Fi alone. In this privacy sensitive world it's going to become unpractical to do it. This Cisco Live session talks about it too:

https://www.ciscolive.com/global/on-demand-library.html?search=BRKEWN-2012#/video/15524933769560023K... around the 50 minute mark.

That said, this study might be an interesting read. I didn't read it completely yet, but it seems like they have already found some ways around the MAC randomization:

https://www.researchgate.net/publication/314361145_A_Study_of_MAC_Address_Randomization_in_Mobile_De...

It may be a cat 'n mouse game in the beginning, but imo that'll die off quickly once lawsuits start hitting.

Also, keep in mind that randomization while connected can cause issues too (exhausted DHCP scopes, duplicate MACs, overflowing MAC tables). So the amount of randomization will likely be limited to doing it on the first connection and saving it in the profile, or maybe very infrequently change it.

[jdsilva]

I have a Pixel 3 running Android 10, so I've been able to play with this a bit. My phone will always use the same MAC to connect to a given SSID. The MAC is different from SSID to SSID, but it's always the same MAC as it was before when I reconnect. 

When I look at the Scanning API I don't actually see much impact here. If I connect to Joe's Coffee Free Wifi in my home town, and then I travel and connect to another Joe's Coffee WiFI,  my MAC is the same. Joe will be able to know that I am a repeat visitor, and that I just visited a new location to me. 

But, the Scanning API is more useful for location than the above example. So let's say I go to a mall. If I don't connect to the Wifi then the Scanning API will report me as a passerby (not connected) and report my location as I move around. I haven't dug deep into it, but I believe even in Android 10 your probe requests use a consistent MAC, so again there's no impact to tacking my movements through the mall. If I do connect to the mall wifi then we're back to the Joe's coffee shop example and the mall will get a consistent view of me regardless of where in the mall I go. 

If the property company that owns the mall has other malls, and uses different SSID's in each mall, then that may pose a challenge. But, a lot of these types of wifi deployments will require you to sign in with your social media ID, or email, etc. Once you do that it doesn't matter how often you MAC changes, they always know it's you. 

[WFS-Matthew]

That's some interesting analysis. However I thought that a passerby was categorised by not being seen often and/or having a weak signal, rather than not being connected, as per this documentation:

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics

So in your scenario, if you are wondering around a mall but not connected to the WiFi, you could be categorised as a visitor. But, usually it is common to disregard devices which do not have a known manufacturer as there can be an awful lot of noise in that space (circa 60% of all data based on what I can see).

[jdsilva]

Sorry, yes you're correct. I used sloppy language here. 

To be totally accurate, the Scanning API reports both a "visitor" and a "passerby" exactly the same. Where the classification comes in is from an external system processing the Scanning API data and making decision about each reported client. 

The ONLY difference in the raw API data is whether or not the "SSID" field is populated or not. If it's populated the client is connected, if it's null then the client is not. The Scanning API does not report how long the client is seen for, only if it is seen during each reporting period, and it does not report a "weak" signal, only what the RSSI is for that client. It's up to you to parse the data as you see fit, or use existing software that has defined classifications for this. 

https://developer.cisco.com/meraki/scanning-api/#!introduction

A disclaimer though, I am referring to the Scanning API v2. I haven't yet really dug into the new beta v3 of the API.

[jdsilva]

I should clarify one more point too. You're referencing the Location Analytics page, which uses data from the Scanning API. What Meraki presents in the Location Analytics is a simple example of what can be done with the Raw Scanning API data. It's very possible to enable the Scanning API to stream the same data to the endpoint of your choosing where you can do whatever you want with the data. 

So the Location Analytics page is only one way to interpret the data and uses the methodology stated in the doc you linked.