#appearance
I’m in Introduction to Algorithms (577) this semester at UW, and I’m enjoying listening to Renault explain how to prove program correctness, DP, network flow, and the conditions under which Dijkstra invented his shortest-path algorithm.
However… Algos is a somewhat unique class for me, given that it is my first course in which it is mandatory to be present during lectures by registering attendance. It accomplishes this through a platform called TopHat, which many students will recognize through its use of displaying participation questions.
To verify that you are actually at the location where attendance is being taken, TopHat asks you to provide a four-length numeric code (which will be provided to you by your lecturer). You type that code on the Student Tophat page, and, oh my, you are marked as present.
However, I think they have caught on to the untested strategy of having friends, which given that they are in the same class section as you, they can be sent messages begging for the code from the comfort of your bed.
So, for the crazy explainer, Tophat allows “Secure Presence”, a feature which, according to them, determines your location as “… determined by [your] By device geolocation or by both geolocation and proximity (for the class and other students).
When I first heard about this system, I was surprised at how much leeway this “geolocation” would give you. A plethora of traditional “IP geolocation” services exist, which use your IP address and ASN – both semi-unique identifiers sent to a webpage when loaded – to identify and trace your location. It provides different results depending on your location. When I was in Madison and NYC, popular IP geolocation services were able to pin me down to within a mile or so of my actual location. In any suburban area, the error reaches city-level.1 Certainly Tophat would not rely on such inaccurate measurements of location when determining attendance – students living in Chadbourne Hall taking lectures in Mosse Humanities (about 250 feet away) would be able to satisfy the attendance requirement. That could be disastrous!
#Geolocation API
Alas, this is not IP geolocation being used by Tophat. As mentioned above, IP geolocation is a very implicit flow – webpages are able to see your IP when you connect to them. However, when attempting to determine your location, Tophat reveals a big scary dialogue from across the death line!
Clearly this is asking something else entirely – something that is probably so precise that it requires my explicit consent.
I will free you from the mystery. This is the Geolocation API, a feature of all modern browsers that allows retrieval of your location. excess More precise degrees (hence permission pop-ups). As of writing this post, IP geolocation is enough to place me somewhere in Madison’s Lakeshore neighborhood (1-2 miles long), but Chrome’s geolocation API is enough to pin me to the exact building – Morgridge Hall – in which I’m sitting. It is orders of magnitude more accurate.
When I first experienced my laptop doing this, my first thought was “How?” There’s nothing special that my laptop’s access would somehow allow my browser to get to a more specific location… correct? my laptop does not have a gps receiver2 This would allow location identification in the same way phones can (and this isn’t just tracking my phone’s GPS, as that’s the same location API available on Windows devices).
#It’s all our fault
When you press “Allow” on the popup, your browser uses accuracy estimation to determine which method gets the most accurate location. Although this could be GPS (if on a cellular-enabled device) or the above IP geolocation, it will probably be most successful. Wi-Fi Positioning SystemA strategy that uses wireless access points around you to identify your location.
This is how it works. After giving your browser permission to access your location, a website has access getCurrentPosition() Celebration. When calling it, your browser asks your operating system for a list of nearby Wi-Fi access points – specifically, their signal strength, SSID, and BSSID.
If those last two are foreign to you, the “SSID” of the network is just the friendly name – for example, UWNet Or eduroamThe BSSID is the MAC address of the access point, which is unique for each device, having a unique identifier per access point This is extremely important, because you can imagine how many APs have the same name. Take a look at AP’s map around the designated campus UWNet,
Okay, great. Now we know exactly which Wi-Fi network you are connected to. But how does this translate to your location on the map? And how do we know where these networks are in the real world?
#warddriving
The notion of linking Wi-Fi networks with their physical locations has been prevalent since the early 2000s. As far as I can tell, Skyhook was the first to do this on a commercially available scale, using a technology called wireless warddriving. This involves getting into the vehicle and driving around while getting as much Wi-Fi network information as possible. Since devices performing network scanning also have reliable knowledge of their position (via GPS), all you have to do is associate the location where you watched the network With its signal strength. Some RSSI trilateration later, and you’ll have an almost accurate map of the Wi-Fi networks you see and their corresponding physical locations.
What’s useful is that, once you have all this data, you can reverse the process – to the user’s device, send a list of the Wi-Fi networks you can see (and their corresponding RSSIs), and get a rough estimate of where this places your device in the world. For a while, everyone’s devices (including Apple devices, up to iOS 3.2) did this, relying on Skyhook or Google’s privately collected list. Interestingly, the latter used its Street View vehicles (those that take pictures of streets) to capture Wi-Fi information for a while.
However, at some point, companies realized the potential benefit of obtaining this information from users of their devices. After all, they’re already repeatedly checking their GPS location and calling home on cell towers, so why not send some anonymized Wi-Fi location data along with it?
So, Apple, Google, and Microsoft devices started doing the same. The location services of their products, by default, began collecting the SSID and BSSID of Wi-Fi hotspots (and their locations) and logging them to others’ devices to use for more accurate location services. And… this is more or less the same thing that modern devices use today. When Chrome tells me that a website wants to use my location, and I allow it, a list of nearby hotspots will be sent to Google — which, because thousands of people with GPS-enabled devices are also pinging the network, allows my computer to get an extremely accurate idea of where I am. So, thanks everyone…?
#Controversy
If you were feeling a little nervous at the thought of your phone collecting and sharing the location and information about every Wi-Fi network you’ve interacted with throughout your life, don’t worry, you’re not alone! There have been many historical incidents of misuse of technology.
From a rough start: Remember how earlier (in WarDriving) I mentioned that Google historically used its Street View cars to get network information for its location services? It turns out they were sniffing more than just the packet’s headers – they were collecting raw 802.11 Wi-Fi data frames, which contained the non-encrypted payload of HTTP packets. I believe very little of the Internet was using HTTPS in 2010, so the reported 600 gigabytes of data certainly included some things users might not want to see.
A larger and more relevant concern comes to the fore regarding the possibility of someone’s location being traced – which is legitimate given its sensitivity. This has been a concern since the inception of WPS, but an older example I found was Eli Bursztein et al’s talk and accompanying blog post “Using the Microsoft Geolocalization API to find out where a Windows laptop is”. At the time, there was a bug where Windows would save a persistent record of every MAC address you connected to, making it possible to retrace someone’s steps (thus, tracking their location as they changed) using one of the many location APIs that were live at the time.
These vulnerabilities are also seen in contemporary times – Eric Rye and Dave Levin of the University of Maryland wrote “Surveying the Public with Wi-Fi-Based Positioning Systems” in 2024, detailing a flaw in Apple’s location services that allowed them to infiltrate the location of approximately two billion BSSIDs by cleverly filtering the MAC address space they were searching for. Their paper is very good, and it touches on some of the real threats potentially posed by information in the hands of an adversary, such as stalking individuals by constantly detecting their router BSSID, or monitoring population density during war by observing the activities of groups of devices (and satellite Internet constellations like Starlink).
Over time, location service providers have improved the security of the APIs they develop. it is supreme This is important given the risks we have discussed, especially given that almost every device made by these companies has by default3We are sending this information to our manufacturers. Almost every company participating in WPS allows you to exclude your BSSID – either by renaming your SSID or specifying a MAC address in some form:
Apple’s instructional opt out page (attached). _nomap) to the SSID.
Google’s page, which offers similar advice.
Microsoft’s form to opt out requires BSSID submission.
#conclusion
If I haven’t mentioned it yet, this technique has a name. This is called Wi-Fi Positioning System (WPS). There is still a vibrant community of Wi-Fi positioning enthusiasts out there – https://wigle.net/ is a crowd-sourced database of recreational waydrivers who have contributed nearly two billion network positions over the past 25 years. You can zoom in on your city and see the Wi-Fi density around you, and you can even check if your own network has been tagged by someone else!
I would also be remiss if I didn’t mention https://beacondb.net/, which is a self-described “public domain wireless geolocation database” that, although I haven’t had time to play with it, seems to be a very promising open version of the trackers commonly used nowadays. Although it doesn’t have as dense a database as other providers, I actually think it’s good to have the lack of uniformity between smaller providers – it shows that the data really is different!
It’s been really fun diving down this rabbit hole to learn how our devices gain access to our location. This is one of the more typical things I take for granted when using my devices, and it certainly didn’t occur to me while in lecture, the only reason I was marked present was because thousands of other students had (without their knowledge) pinged servers all over the world.