Apple's huge database, which usually records the locations of Wi-Fi base stations to the nearest metre, has apparently been exploited without hindrance: With little effort, attackers are able to create a ‘global snapshot’ of all the location data of the WLANs recorded there. This allows them - over a longer period of time - to track changes in the location of the routers usually belonging to a household or sometimes even of individuals, as two researchers from the University of Maryland have now demonstrated.
The researchers consider it particularly problematic that Apple's Wi-Fi database can be read out practically unhindered and immediately provides the location data for ‘several hundred’ additional BSSIDs (the physical MAC addresses of the routers) to the requesting client without being asked via an apparently unlimited API. In this respect, Apple's Wi-Fi database also differs fundamentally from other Wi-Fi databases, such as the one operated by Google.
Apple's got one, so does Google, and Microsoft. They're common tools for scam baiters tracking down call centres and individual scammers. Pretty effective actually.
They've got beacon location data, yes, but Apple is the only one that gives up that information without first conforming that the query is coming from someone who sees that BSSID. As OP notes:
In this respect, Apple's Wi-Fi database also differs fundamentally from other Wi-Fi databases, such as the one operated by Google.
If you click through to the paper, it describes 2 approaches for using BSSIDs to identify location:
Client submits a query listing each BSSID and its signal strength, and the server calculates position and returns where it believes the query is coming from.
Client submits a query listing each BSSID it's interested in, and the server responds with the location of each BSSID so that the client can calculate its own position.
See the problem there? Approach 2 gives more raw information away, by outsourcing the positioning calculation to untrusted clients.
And the paper outlines how Apple goes even further than that:
Apple’s Wi-Fi geolocation API [4] works in the latter manner, but with an added twist: In addition to the geolocations of the BSSIDs the client submits, Apple’s API opportunistically returns the geolocations of up to several hundred more BSSIDs nearby the one requested. These unrequested BSSID geolocations are presumably then cached by the client, which no longer needs to request the locations of the nearby BSSIDs it may soon encounter, e.g., as the user walks down a city street.
It goes on later:
Apple’s WPS API is free and places few restrictions on its use. It requires neither an API key, authentication, nor an Apple device; our measurement software is written in Go and runs on Linux. Moreover, Apple appears to make no attempt to filter physically impossible queries. The BSSIDs submitted to the WPS need not be physically proximate to each other nor to the device submitting the query; Apple’s WPS will respond with geolocations for BSSIDs on two different continents in the same request to a querier on a third.
That's the discussion here. Apple keeps a large database, like many other big tech/mapping firms, but does nothing to keep that database hard for strangers to scrape in bulk.
In contrast, Google uses the first approach and keeps the information a bit more restricted by performing the location calculation at the server:
Han et al. reverse-engineered Google’s WPS’s method of operation [17]. Google’s WPS functions differently than Skyhook’s and Apple’s insofar as Google’s service attempts to geolocate the device submitting the query, providing it with only the device’s computed position given a list of BSSIDs from the client.
So it's possible to run this type of service with this type of database, without sharing BSSID locations with anyone else who asks.