Cellular networks can determine your location based on which cell towers your device connects to.
This is well-known. I have served on a jury where the prosecution obtained location data from cell towers. Since cell towers are sparse (especially before 5G), the accuracy is in the range of tens to hundreds of metres2.
But this is not the whole truth, because cellular standards have built-in protocols that make your device silently send GNSS (i.e. GPS, GLONASS, Galileo, BeiDou) location to the carrier. This would have the same precision as what you see in your Map apps, in single-digit metres.
In 2G and 3G this is called Radio Resources LCS Protocol (RRLP)
So the network simply asks “tell me your GPS coordinates if you know them” and the phone will respond3.
In 4G and 5G this is called LTE Positioning Protocol (LPP)
RRLP, RRC, and LPP are natively control-plane positioning protocols. This means that they are transported in the inner workings of cellular networks and are practically invisible to end users4.
It’s worth noting that GNSS location is never meant to leave your device. GNSS coordinates are calculated entirely passively, your device doesn’t need to send a single bit of information. Using GNSS is like finding out where you are by reading a road sign: you don’t have to tell anyone else you read a road sign, anyone can read a road sign, and the people who put up road signs don’t know who read which road sign when.
These capabilities are not secrets but somehow they have mostly slid under the radar of the public consciousness. They have been used in the wild for a long time, such as by the DEA in the US in 200656:
[T]he DEA agents procured a court order (but not a search warrant) to obtain GPS coordinates from the courier’s phone via a ping, or signal requesting those coordinates, sent by the phone company to the phone.
And by Shin Bet in Israel, which tracks everyone everywhere all the time7:
The GSS Tool was based on centralized cellular tracking operated by Israel’s General Security Services (GSS). The technology was based on a framework that tracks all the cellular phones running in Israel through the cellular companies’ data centers. According to news sources, it routinely collects information from cellular companies and identifies the location of all phones through cellular antenna triangulation and GPS data7.
Notably, the Israeli government started using the data for contact tracing in March 202078, only a few weeks after the first Israeli COVID-19 case. An individual would be sent an SMS message informing them of close contact with a COVID patient and required to quarantine. This is good evidence that the location data Israeli carriers are collecting are far more precise than what cell towers alone can achieve.
A major caveat is that I don’t know if RRLP and LPP are the exact techniques, and the only techniques, used by DEA, Shin Bet, and possibly others to collect GNSS data; there could be other protocols or backdoors we’re not privy to.
Another unknown is whether these protocols can be exploited remotely by a foreign carrier. Saudi Arabia has abused SS7 to spy on people in the US9, but as far as I know this only locates a device to the coverage area of a Mobile Switching Center, which is less precise than cell tower data. Nonetheless, given the abysmal culture, competency, and integrity in the telecom industry, I would not be shocked if it’s possible for a state actor to obtain the precise GNSS coordinates of anyone on earth using a phone number/IMEI.
Apple made a good step in iOS 26.3 to limit at least one vector of mass surveillance, enabled by having full control of the modem silicon and firmware. They must now allow users to disable GNSS location responses to mobile carriers, and notify the user when such attempts are made to their device.
https://transition.fcc.gov/pshs/911/Apps Wrkshp 2015/911_Help_SMS_WhitePaper0515.pdf ↩
https://laforge.gnumonks.org/blog/20101217-learning_about_gps/ ↩
Comment on United States v. Skinner, 690 F.3d 772 (6th Cir. 2012) https://harvardlawreview.org/print/vol-126/sixth-circuit-holds-that-pinging-a-targets-cell-phone-to-obtain-gps-data-is-not-a-search-subject-to-warrant-requirement-ae-united-states-v-skinner-690-f-3d-772-6th-cir-2012-rehae/ ↩
https://www.cato.org/blog/skinning-fourth-amendment-sixth-circuits-awful-gps-tracking-decision ↩
https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know ↩
Eran Toch and Oshrat Ayalon. 2023. How Mass surveillance Crowds Out Installations of COVID-19 Contact Tracing Applications. https://doi.org/10.1145/3579491 ↩ ↩2 ↩3
https://www.nytimes.com/2020/03/16/world/middleeast/israel-coronavirus-cellphone-tracking.html ↩
https://www.theguardian.com/world/2020/mar/29/revealed-saudis-suspected-of-phone-spying-campaign-in-us ↩
At my job, we had a CAA record that looked like this
example.com CAA 0 issue "letsencrypt.org"
This allows Let’s Encrypt to issue example.com certs and *.example.com wildcard certs. The 0 is a flag used for CA-specific features, we can ignore it.
A bit later, we needed another CA to issue both single-domain and wildcard certificates on our domain. Without realising the issue directive allows for both, someone appended both issue and issuewild directives:
example.com CAA 0 issue "letsencrypt.org"
CAA 0 issue "amazon.com"
CAA 0 issuewild "amazon.com"
A bit redundant, but it looks like it should still work.
…until our existing Let’s Encrypt wildcard certificates suddenly stopped renewing.
Turns out that the issue directive allows for wildcard issuance only in the absence of any issuewild directive1. As soon as an issuewild directive is added, CAs with only issue are forbidden from issuing wildcards.
This is a bad design. An additive modification should not remove capabilities of unrelated, existing entries.
On the other hand, suppose you want only one CA to issue only single-domain certificates for your domain, then you must do something like
issue "letsencrypt.org"
issuewild ";"