Satellite navigation grew from one system to four global ones: GPS was declared operational in 1995, GLONASS in 1993 with a full constellation in 1995, Galileo began Initial Services on 15 December 2016 and BeiDou-3 was completed on 31 July 2020, with India's NavIC and Japan's QZSS serving their regions. Only Galileo's open service authenticates its navigation data today, through OSNMA, declared operational on 24 July 2025.
That is the short answer. The longer one matters if you build location apps, care about your own location privacy, or run systems that quietly take their time from a GPS antenna on the roof. Every date below is checked against gps.gov, the European GNSS Service Centre, ESA, the GLONASS information centre, beidou.gov.cn, ISRO, CISA, and Apple's and Google's own documentation.
Key takeaways
- GPS has been operational since 1995. Selective Availability, the deliberate degradation of civil accuracy, was switched off just after midnight EDT at the end of 1 May 2000, and in September 2007 the US government decided GPS III would be built without it.
- Modern GPS adds three civil signals to the legacy L1 C/A: L2C (1227 MHz, first launched 2005), L5 (1176 MHz, first full transmitter May 2010) and L1C (1575 MHz, first launched December 2018). As of gps.gov's last update, L2C and L5 are still "pre-operational" and L1C is "developmental".
- Galileo Initial Services began on 15 December 2016. Its open service is broadcast on E1 and E5, and OSNMA authenticates the I/NAV navigation message on the E1-B component. It does not encrypt or authenticate the ranging signal itself.
- Jamming drowns a receiver in noise so it loses the fix; spoofing feeds it plausible but false signals so it computes a wrong position or time and keeps going. Jamming is loud and obvious; spoofing is designed not to be.
- Executive Order 13905 (12 February 2020) asked Commerce to publish PNT profiles within a year, DHS to plan vulnerability tests, and agencies to write PNT requirements into federal contracts.
- On iOS, apps ask for While Using or Always, and since iOS 14 users can turn Precise Location off per app. On Android, coarse versus fine and foreground versus background are separate permissions, and since Android 12 users can pick Approximate even when an app asks for Precise.
The dated timeline: constellations, signals and phone permissions
Every row below comes from the operator or vendor in the source column.
| Date | Event | Track | Source |
|---|---|---|---|
| Oct 1982 | First GLONASS flight test satellite, Kosmos-1413, launched | Constellation | GLONASS IAC |
| 1993 | GLONASS formally declared operational | Constellation | GLONASS IAC |
| 1995 | GLONASS reaches a full constellation of 24 first generation satellites | Constellation | GLONASS IAC |
| 1995 | GPS declared operational | Constellation | gps.gov FAQ |
| 1 May 2000 | GPS Selective Availability switched off, a few minutes past midnight EDT after the end of 1 May | Signal policy | gps.gov |
| 2002 | GLONASS down to 7 satellites; the federal programme "Global Navigation System for 2002 to 2011" begins its restoration | Constellation | GLONASS IAC |
| 2005 | First GPS satellite with L2C (Block IIR-M) launched | Signal | gps.gov |
| Sep 2007 | US decides GPS III will be built without Selective Availability | Signal policy | gps.gov |
| May 2010 | First GPS Block IIF satellite with a full L5 transmitter launched | Signal | gps.gov |
| Jun 2011 | GPS "Expandable 24" reconfiguration completed, effectively a 27 slot constellation | Constellation | gps.gov |
| Apr 2014 | CNAV messages begin on L2C and L5 | Signal | gps.gov |
| 2016 | India renames IRNSS as NavIC | Constellation | gps.gov |
| 15 Dec 2016 | Galileo Initial Services begin | Constellation | ESA |
| 27 Dec 2017 | BeiDou B2a open service ICD version 1.0 published | Signal | beidou.gov.cn |
| 2018 | QZSS services officially start with 4 satellites | Constellation | gps.gov |
| 3 Jun 2018 | BeiDou B1C open service ICD version 1.0 published | Signal | beidou.gov.cn |
| Dec 2018 | First GPS satellite with L1C (GPS III) launched | Signal | gps.gov |
| 12 Feb 2020 | Executive Order 13905 on responsible use of PNT signed (published 18 Feb 2020) | Policy | Federal Register |
| 31 Jul 2020 | Ceremony marks completion of the BeiDou-3 system | Constellation | beidou.gov.cn |
| 2020 | iOS 14 adds accuracy authorization (Precise Location) to Core Location | Phone | Apple developer docs |
| 2021 (Android 12) | Users can grant only approximate location even when an app requests fine | Phone | Android developers |
| 15 Nov 2021 | Galileo OSNMA Public Observation Phase begins | Authentication | GSC |
| Feb 2025 | DHS publishes Best Practices for Resilient PNT Supporting Critical Infrastructure | Policy | gps.gov resilience page |
| 24 Jul 2025 | Galileo OSNMA Initial Service declared operational | Authentication | GSC |
Note the gaps: L2C has been in orbit since 2005 and gps.gov still lists it as pre-operational, and phone accuracy controls only arrived in 2020 and 2021.
When did each constellation reach operational capability?
"Operational" means different things to different operators, so each is quoted in its own terms.
GPS
GPS is owned by the US government and operated by the US Space Force. According to gps.gov, the government commits to at least 24 operational satellites 95 percent of the time, in six orbital planes at about 20,200 km, each circling the Earth twice a day. The gps.gov FAQ states plainly that GPS was declared operational in 1995 and has never been deactivated since.
Counts on gps.gov are dated and inconsistent: the space segment page says 31 operational satellites as of 3 July 2023, the FAQ says 25 for the same date. For current numbers, gps.gov points to the US Coast Guard Navigation Center.
GLONASS
The Russian Information and Analysis Center for PNT says flight tests started in October 1982, the system was declared operational in 1993 and reached a full constellation of 24 first generation satellites in 1995. Funding cuts then let the constellation decay to 7 satellites by 2002, too few to cover even Russian territory. A federal programme covering 2002 to 2011 restored it with GLONASS-M and later GLONASS-K satellites. The nominal design is 24 satellites in three planes at 64.8 degrees inclination and about 19,100 km altitude.
Galileo
Galileo is owned by the European Union. EUSPA runs its operations and service provision, and ESA handles system design and evolution. ESA's Galileo page states that Initial Services became available on 15 December 2016, and the GSC constellation status page, fetched on 23 October 2026, listed 28 satellites as usable and four as not usable. EUSPA stresses that, unlike the other global systems, Galileo is a civilian system.
BeiDou
China's system went through three generations. gps.gov describes BDS as formally commissioned in 2020 with 35 satellites in the operational system, and beidou.gov.cn records the ceremony marking the completion of BeiDou-3 on 31 July 2020. BeiDou was previously known as Compass.
NavIC and QZSS: the regional systems
ISRO describes the Indian Regional Navigation Satellite System as an independent regional system covering India and about 1,500 km beyond its boundary, with a Standard Positioning Service for all users and an encrypted Restricted Service for authorised users, and an expected position accuracy better than 20 m in the primary service area. gps.gov lists 7 satellites and notes the 2016 renaming to NavIC. Japan's QZSS complements GPS over East Asia and Oceania; gps.gov records the start of official services in 2018 with 4 satellites and now 7 or more.
The signal comparison table
The second table compares civil signals. Authentication here means cryptographic protection of the navigation data a civil user can verify, not the military encrypted services that every operator also runs.
| System | Civil signals (examples) | Carrier | Modernisation status (per operator) | Civil data authentication |
|---|---|---|---|---|
| GPS | L1 C/A | 1575 MHz (L1) | Legacy signal, still broadcast | None |
| GPS | L2C | 1227 MHz (L2) | Pre-operational; on 25 satellites as of 3 Jul 2023 | None |
| GPS | L5 | 1176 MHz | Pre-operational, message set "unhealthy"; on 18 satellites as of 3 Jul 2023; 24 satellites projected around 2027 (as of Jan 2020) | None |
| GPS | L1C | 1575 MHz (L1) | Developmental, no navigation data; on 6 satellites as of 3 Jul 2023 | None |
| Galileo | E1 open service (E1-B carries I/NAV) | L1 band, shared with GPS L1 | Operational since Initial Services, Dec 2016 | OSNMA on E1-B I/NAV, Initial Service since 24 Jul 2025 |
| Galileo | E5 open service (E5a, E5b) | E5 band | Operational; dual frequency OS with E1 | Not covered by OSNMA |
| GLONASS | L1OF, L2OF (FDMA) | 1602 MHz, 1246 MHz centre | In use | None |
| GLONASS | L3OC, L1OC, L2OC (CDMA) | 1202, 1600, 1248 MHz | On newer GLONASS-M and GLONASS-K satellites | None |
| BeiDou | B1I, B3I, B1C, B2a, B2b | B1, B2, B3 bands | Open service ICDs published 2017 to 2020 | None in the open service |
| NavIC | Standard Positioning Service | Regional | Operational in primary service area | Restricted Service is encrypted for authorised users only |
A note on the GPS rows: L1C and L1 C/A share a carrier frequency but are different signals. gps.gov warns that "L1C should not be confused with L1 C/A". L1C was designed with Europe as a common civil signal for GPS and Galileo, which is why modern chipsets can track GPS L1C and Galileo E1 with much of the same hardware.
What civil signals exist and why do they matter?
For two decades, almost every civilian receiver used one publicly documented signal on one frequency: L1 C/A. Three problems followed.
The ionosphere. Radio signals slow down as they pass through the charged upper atmosphere, and the delay depends on frequency. A single frequency receiver has to estimate that delay with a model. A dual frequency receiver measures it directly by comparing two signals. gps.gov notes that combining L2C with L1 C/A enables ionospheric correction, so that "Civilians with dual-frequency GPS receivers enjoy the same accuracy as the military (or better)". The same logic applies to Galileo E1 plus E5a, which is why recent phones advertise dual frequency GNSS. Space weather makes this problem worse during solar storms, which our post on space weather and satellite risk covers.
Safety of life. L5 sits in a band reserved for aviation safety services, with higher power and wider bandwidth than L1 C/A. gps.gov describes L5 as designed for safety of life transport, and explains that using L1 C/A, L2C and L5 together ("trilaning") may enable sub-metre accuracy without augmentation.
Interoperability. L1C and Galileo E1 share a design lineage and a frequency, and gps.gov says BeiDou and QZSS are adopting L1C-like signals. More visible satellites matters in cities where buildings block most of the sky.
Security. More signals and constellations make a receiver harder to deny and harder to fool, but only if it checks them against each other. Tracking four systems while trusting the strongest signal adds availability, not integrity.
How do phones combine GNSS with Wi-Fi and cell positioning?
A phone rarely uses satellite navigation alone. Apple's support article on Location Services says that, with your permission, apps can use information from cellular, Wi-Fi, GPS networks and Bluetooth to determine your location. When walls, roofs or buildings block the sky, "your device uses Wi-Fi or cellular networks to determine your position until the GPS satellites are visible again."
In broad terms, the phone first matches the Wi-Fi access points and cell towers it can hear against a database of known locations, which is fast and works indoors. Network assistance then tells the GNSS chip which satellites to look for, so a first fix takes seconds rather than minutes; Apple advises setting date and time automatically to help GPS accuracy. A fused provider combines all of this with motion sensors, and apps receive that fused answer with an accuracy estimate.
Those databases are built from phones. Apple states that with Location Services on, the device periodically sends geotagged locations of nearby Wi-Fi hotspots and cell towers to Apple, and an iPhone in transit also sends GPS locations, speed, direction and barometric pressure for traffic and atmospheric correction databases. Apple says this data is encrypted and does not personally identify you. Access point owners can opt out by ending the network name with _nomap.
On Android, Google's documentation describes "Location Accuracy", also known as Google Location Services. When it is on, it can collect data to improve location accuracy, and scanning for Wi-Fi helps find the device more accurately. With device location off, Google says apps cannot get the device location, but you can still get local results and ads based on your IP address, and emergency location services or your carrier can still send your location when you call or text an emergency number. Apple likewise says your iPhone's location may be used on an emergency call regardless of whether Location Services is enabled.
So turning off location stops apps from reading it; it does not make the phone unlocatable by its network.
What is the difference between jamming and spoofing?
GNSS signals are extremely weak by the time they reach the ground, which makes them easy to overpower. gps.gov lists the sources of interference as radio emissions in nearby bands, intentional or unintentional jamming, and naturally occurring space weather. Our post on GPS interference sources covers each one in depth. The two deliberate threats work very differently.
| Jamming | Spoofing | |
|---|---|---|
| What it does | Raises the noise floor so the receiver cannot track satellites | Transmits counterfeit signals that look like real satellites |
| What the receiver sees | Loss of fix, falling signal to noise ratio, no position | A position or time that looks valid but is wrong |
| How visible it is | Obvious: the device reports no fix | Subtle by design; the device keeps working |
| Main risk | Denial of service for navigation and timing | Wrong decisions made with confidence: wrong route, wrong timestamp, wrong geofence |
| What helps | Backup sources, holdover clocks, alerts on loss of fix | Cross checks between constellations and sensors, data authentication, sanity checks on jumps |
| Legal status in the US | Illegal to market, sell or use, per gps.gov and the FCC | Illegal to transmit without authorisation |
CISA's PNT page notes that "advances in technologies have made the ability to broadcast mock GPS signals relatively simple". The US Space Force's Joint Commercial Operations cell publishes daily unclassified heat maps of intentional interference and spoofing, which gps.gov shows on its spectrum page. Our post on what agencies document about navigation disruption collects those reports.
Spoofing matters most where GNSS supplies time rather than position. gps.gov notes that each satellite carries multiple atomic clocks and a receiver can determine time to within 100 billionths of a second, which is why GNSS receivers sit behind cellular networks, grid synchronisation and data centre time servers; our post on GPS timing as the hidden dependency in your stack traces that chain, and space weather and IT adds a natural cause.
This post deliberately stops at the concept. How a spoofer works in detail is not needed to defend against it, and the defences are the same either way: do not trust one source of position or time, check for physically impossible jumps, and know what your system does when the fix goes bad.
Which constellations offer signal authentication, and what does OSNMA cover?
Among the open civil services, Galileo is the one that has declared authentication operational. The European GNSS Service Centre describes OSNMA as a free data authentication function that gives receivers "the assurance that the received Galileo navigation message is coming from the system itself and has not been modified."
What it actually covers, in the GSC's terms:
- The navigation message, not the signal. OSNMA authenticates the I/NAV navigation message on the E1-B signal component. It uses fields that were previously reserved in that message, so it adds no overhead and does not change navigation performance.
- A broadcast protocol called TESLA. OSNMA adapts TESLA (Timed Efficient Stream Loss-Tolerant Authentication), which uses delayed disclosure of keys. Because of that, the receiver must already know the time to within a bound, set between 30 and 300 seconds depending on the operating mode, before it can trust what it processes.
- A key setup step. A receiver needs a one-off initialisation that installs certified cryptographic material (a Merkle tree root) from the GSC and EUSPA sites. Keys can later be renewed over the air or by downloading new material. The receiver must protect the integrity of that stored material; confidentiality is not required.
- A roadmap with dates. The Public Observation Phase ran from 15 November 2021 until the Initial Service declaration on 24 July 2025.
What it does not cover: OSNMA does not prove that the ranging signal itself, the timing of its arrival that gives you distance, came from a satellite. A replayed or delayed genuine signal can still carry a validly signed message. It also only helps receivers that implement it; the GSC maintains a list of receivers that do. GPS, GLONASS, BeiDou and NavIC open services do not offer comparable civil data authentication today. Our post asking whether Galileo OSNMA stops GPS spoofing goes deeper on these limits.
If you rely on GNSS time or position in infrastructure, ask your receiver vendor whether OSNMA is supported and enabled, and what the receiver does when authentication fails.
What did the US PNT executive order ask for?
Executive Order 13905, "Strengthening National Resilience Through Responsible Use of Positioning, Navigation, and Timing Services", was signed on 12 February 2020 and published in the Federal Register on 18 February 2020. Its policy section says it is US policy "to ensure that disruption or manipulation of PNT services does not undermine the reliable and efficient functioning of its critical infrastructure."
The concrete asks in section 4:
- PNT profiles within one year. Commerce was to publish profiles that help organisations identify PNT dependent systems, choose PNT services, detect disruption and manipulation, and manage the risk, reviewed every two years. NIST published the Foundational PNT Profile in February 2021, per gps.gov.
- Federal Radionavigation Plan updates referring to the profiles.
- A vulnerability test plan within one year from DHS, testing critical infrastructure under PNT disruption and manipulation.
- Contract language within 90 days of the profiles, later incorporated into federal contracts by the Federal Acquisition Regulatory Council.
- Reporting on adoption within a year and every two years after.
The follow-on documents are listed on gps.gov's resilience page, including the DHS Resilient PNT Conformance Framework (version 2.0, May 2022), the Resilient PNT Reference Architecture (June 2022), CISA's Federal PNT Services Acquisitions Guidance (April 2024) and the DHS Best Practices for Resilient PNT Supporting Critical Infrastructure (February 2025).
How do iOS and Android location permissions work?
Both platforms separate two questions: when can the app read location, and how precisely.
iOS and iPadOS
According to Apple's documentation:
- While Using. The first request prompts with the developer's reason. An app is "in use" in the foreground, or while using location in the background with a blue pill in the status bar.
- Always. An app granted While Using may later ask for background access; iOS then periodically reminds you, shows the accessed locations on a map and asks whether to keep allowing it.
- Allow Once. Since iOS 13, iPadOS 13 and watchOS 6, Allow Once grants access for a single session.
- Precise Location. In Settings, Privacy and Security, Location Services, each app has a Precise Location switch. Apple's user guide says to turn it off "to share only your approximate location". On the developer side, Core Location's
accuracyAuthorizationproperty andrequestTemporaryFullAccuracyAuthorization(withPurposeKey:)method were introduced in iOS 14.0, which is when this control arrived.
Android
According to Google's Android help and developer documentation:
- Four user facing choices. Settings, Location, App location permissions groups apps under "Allowed all the time", "Allowed only while in use", "Ask every time or allow when I share" and "Not allowed".
- Two accuracy levels. Approximate means the app can tell the device is within an area of about 3 square kilometres. Precise is usually within about 50 metres and sometimes within a few metres. Each app with location access has a "Use precise location" switch.
- Separate background permission. Since Android 10 (API level 29), background access requires declaring
ACCESS_BACKGROUND_LOCATION. On earlier versions, foreground access automatically included background access. - Incremental requests enforced. If an app targets Android 11 (API level 30) or higher and asks for foreground and background location at the same time, the system ignores the request and grants neither.
- Approximate by user choice. On Android 12 (API level 31) or higher, users can grant only approximate location even when the app asks for fine. If they later downgrade an app from precise to approximate, the system restarts the app's process.
- The location button. Google's developer docs now describe a location button for session based, one-time access, and say that apps targeting Android 17 (API level 37) or later that only need session based location must use it under Google Play policy.
Which system services use location, and how do you review them?
On iPhone, Apple's user guide says several system services, such as location-based suggestions and location-based ads, use Location Services. Go to Settings, Privacy and Security, Location Services, System Services to see the status of each service, switch each one on or off, and choose whether the status bar shows an icon when system services use your location. The same screen is where you control the crowd sourced Wi-Fi and cell contributions described above. To reset everything to factory defaults, Apple points to Settings, General, Transfer or Reset, Reset, Reset Location and Privacy.
On Android, Settings, Location shows device level services. Google lists Location Accuracy, emergency location services, Find Hub, location sharing in Google Maps, earthquake alerts, location for time zone and Timeline as location based services. Each has its own switch or account setting. Manufacturers may add their own entries.
A practical review: sort apps into needs location (maps), nice to have (weather) and no reason at all. Give the first group While Using, with Precise only for turn by turn use; give the second Approximate or ask every time; set the third to Never. Question anything with Always, then switch off system services you do not use, especially location-based suggestions and ads.
How should apps request location with least privilege?
Least privilege for location has four parts: ask for the coarsest accuracy that works, ask only when the user starts a feature that needs it, avoid background access unless the feature cannot work without it, and keep what you collect for as short a time as possible. The decision table below maps common features to the narrowest grant.
| Feature | iOS grant | Android grant | Why |
|---|---|---|---|
| Local weather, region specific content | While Using, Precise off (NSLocationDefaultAccuracyReduced) | ACCESS_COARSE_LOCATION only | Area level is enough |
| Store finder, "near me" search | While Using, reduced accuracy; temporary full accuracy only if the user asks for directions | Coarse, request fine only from the directions screen | Precise only for the moment it is needed |
| Share my location once in chat | Allow Once / While Using | Location button or coarse plus fine, foreground only | One time action |
| Turn by turn navigation | While Using, Precise | Fine plus coarse, foreground service of type location | Needs accuracy, but only while navigating |
| Geofence reminders, family sharing | Always, after While Using is granted and the feature is explained | Background location requested separately after foreground | Genuinely needs background access |
| Analytics, ads attribution | No location | No location | No user facing feature needs it |
Step by step: implementing and auditing location access
The steps below are configuration and code from Apple's and Google's documentation, plus commands to see what your own devices and hosts are actually doing. None of them change GNSS behaviour.
1. iOS: declare purpose strings and default to reduced accuracy
In Info.plist, declare the purpose strings Apple requires, and opt in to reduced accuracy by default if your app does not need precise location for most features:
<key>NSLocationWhenInUseUsageDescription</key>
<string>Shows stores near you while you use the app.</string>
<!-- Only if a feature truly needs background access -->
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Reminds you when you arrive at a saved store.</string>
<!-- Start with approximate location -->
<key>NSLocationDefaultAccuracyReduced</key>
<true/>
<!-- Explain each temporary full accuracy request -->
<key>NSLocationTemporaryUsageDescriptionDictionary</key>
<dict>
<key>Directions</key>
<string>Precise location gives accurate walking directions to the store.</string>
</dict>
2. iOS: ask for While Using, then full accuracy only when needed
import CoreLocation
final class LocationGate: NSObject, CLLocationManagerDelegate {
private let manager = CLLocationManager()
func start() {
manager.delegate = self
manager.desiredAccuracy = kCLLocationAccuracyKilometer
manager.requestWhenInUseAuthorization()
}
// Call this only from the directions screen
func needPreciseForDirections() {
if manager.accuracyAuthorization == .reducedAccuracy {
manager.requestTemporaryFullAccuracyAuthorization(withPurposeKey: "Directions")
}
}
}
requestWhenInUseAuthorization() and requestAlwaysAuthorization() date back to iOS 8; the accuracy APIs are iOS 14 and later. Ask for Always only after the user turns on a feature that needs it.
3. Android: declare coarse first, fine only if needed, background separately
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<!-- Always include coarse -->
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<!-- Only if a feature benefits from precise location -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<!-- Only if a core feature needs background access (Android 10+) -->
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
<application>
<service
android:name=".NavigationService"
android:foregroundServiceType="location" />
</application>
</manifest>
4. Android: request coarse and fine together, and handle approximate
Google's documentation says not to request ACCESS_FINE_LOCATION on its own: on Android 12 and higher, request fine and coarse in one runtime request, and expect the user may grant only coarse.
val locationRequest = registerForActivityResult(
ActivityResultContracts.RequestMultiplePermissions()
) { grants ->
when {
grants[Manifest.permission.ACCESS_FINE_LOCATION] == true -> startPreciseFeature()
grants[Manifest.permission.ACCESS_COARSE_LOCATION] == true -> startApproximateFeature()
else -> explainWithoutLocation()
}
}
fun onFindNearbyTapped() {
locationRequest.launch(arrayOf(
Manifest.permission.ACCESS_FINE_LOCATION,
Manifest.permission.ACCESS_COARSE_LOCATION
))
}
Request ACCESS_BACKGROUND_LOCATION in a later, separate step, after foreground access is granted and the user has turned on the feature that needs it. If you request both at once while targeting Android 11 or higher, the system grants neither.
5. Audit what location permissions your Android build actually declares
Google's docs ask developers to check whether SDKs in the app depend on location permissions, because merged manifests can pull permissions in from libraries. Check the final APK, not just your own manifest:
# From the Android SDK build-tools: list permissions in the built APK
aapt2 dump permissions app/build/outputs/apk/release/app-release.apk | grep -i location
# On a test device with USB debugging on: see what a given app was granted
adb shell dumpsys package com.example.app | grep -i location
# Revoke background location from an app on your own test device
adb shell pm revoke com.example.app android.permission.ACCESS_BACKGROUND_LOCATION
If ACCESS_FINE_LOCATION or ACCESS_BACKGROUND_LOCATION appears and you did not add it, find which dependency's manifest contributed it (the merged manifest report in your build output shows this) and decide whether that SDK belongs in the app.
6. On Linux hosts that read GNSS: know your gpsd version
Many time servers, vehicles and embedded boards read GNSS through gpsd. Treat it like any other package:
# Which gpsd is installed and running
gpsd -V
systemctl status gpsd
# Which package version the distribution shipped
dpkg -l | grep -i gpsd # Debian, Ubuntu
rpm -qa | grep -i gpsd # RHEL, Fedora
# Is chrony actually using a GNSS reference, or only network servers?
chronyc sources -v
If chronyc sources shows a GNSS or PPS reference as selected, that host's clock depends on your roof antenna; make sure independent sources exist for when it fails or drifts. Our post on CVE-2026-58459 in gpsd's gpsprof shows why the gpsd package version itself is worth tracking.
What does location data reveal, and how long is it kept?
One location point says where a device was. Weeks of precise background points reveal a home from overnight rests, a workplace from weekday clusters, and visits to clinics, places of worship, shelters or a partner's home.
Retention depends on who holds the data:
- On the device. Google's Android documentation says that when Timeline is on, even when Google apps are not in use, your precise device location is regularly saved to your device. Timeline is off by default for a Google Account and is only turned on if you opt in. If you turn on backup, Google Maps keeps an encrypted copy on Google's servers. Timeline data is kept according to your auto-delete settings or until you delete it.
- At the app. Once an app receives your location, what happens next is governed by its own terms and privacy policy. Apple says so directly: "If you allow third-party apps or websites to use your data or your current location, you're subject to their terms, privacy policies, and practices." That includes any SDK the developer embedded.
For developers: round coordinates when the feature does not need them, keep location out of analytics and crash logs, and set a deletion schedule for trip histories.
Where Safeguard fits
Safeguard does not configure phones, manage devices, monitor radio interference or validate GNSS signals, and nothing in your location privacy settings depends on it. The honest connection is software components. gpsd, NTP and PTP daemons on Linux hosts, and the location and analytics SDKs inside mobile apps are all third party code that you ship. Safeguard scans repositories, container images and SBOM files for their dependencies, matches components against vulnerability databases, ranks findings with reachability analysis and shows which of your projects contain a given component and version. When the next gpsd advisory lands, that is how you find which images carry the affected version. It does not audit app permissions; that is the APK check in step 5. Our post on using SBOMs to find affected products fast walks through the inventory workflow.
Fix it without waiting for upstream
GNSS itself is satellites and radios, but the code that reads it is ordinary open source and vendor software: gpsd on time servers and vehicles, chrony and PTP daemons, and the location SDKs inside every app that asks for your position. When one of those components has a vulnerability, the same patch discipline applies as for any other dependency, while receiver firmware and phone operating systems still have to come from their vendors.
Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.
3. Gold Registry: start from components that are already fixed
registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
Common mistakes
- Assuming more constellations means authenticated data. Only Galileo OSNMA authenticates civil navigation data, and only on E1-B, and only if the receiver implements it.
- Believing OSNMA stops all spoofing. It authenticates the message, not the arrival time of the signal, and it depends on the receiver already having roughly correct time.
- Running a time server with GNSS as the only reference. If the antenna is jammed or spoofed, every host downstream inherits the error. Configure independent sources and alert when the GNSS reference is deselected.
- Requesting
ACCESS_FINE_LOCATIONby itself on Android. On Android 12 the system may ignore the request; request fine and coarse together and handle approximate. - Asking for background location on first launch. It fails outright on Android 11 and higher if bundled with foreground, and users rightly refuse it on both platforms when no feature explains it.
- Not checking what SDKs add. A merged Android manifest can declare location permissions your own code never uses. Google's docs ask developers to check exactly this.
FAQ
When did GPS become fully operational?
The gps.gov FAQ states that GPS was declared operational in 1995 and has never been deactivated since. Selective Availability, which degraded civilian accuracy to as much as about 100 metres, was switched off on 1 May 2000, and civil accuracy improved tenfold.
What is the difference between GPS and GNSS?
GNSS is the general term for any satellite navigation constellation. GPS is the US system; Galileo, GLONASS and BeiDou are the other global ones, and NavIC and QZSS are regional.
Can GPS track my phone?
No. The gps.gov FAQ explains that GPS satellites are one way beacons, "like lighthouses", that do not track anything on the ground. Your phone computes its own position. Whether anyone else learns it depends on the apps, services and networks you allow to read it.
What is the difference between GPS jamming and spoofing?
Jamming overwhelms the receiver with noise so it loses its fix, which is obvious. Spoofing sends counterfeit satellite like signals so the receiver computes a wrong position or time and carries on as if nothing were wrong, which is why it is more dangerous for systems that act on location or time automatically.
Does Galileo OSNMA stop spoofing?
It makes forging Galileo navigation data much harder for receivers that implement it. It does not authenticate the ranging signal itself, so it does not stop every form of manipulation, and the receiver must already know the time within a set bound.
What is the difference between precise and approximate location?
On Android, approximate means the app can place the device within an area of about 3 square kilometres, while precise is usually within about 50 metres and can be a few metres. On iPhone, turning off Precise Location for an app shares only your approximate location. Both platforms let you set this per app.
Should I allow apps to use location "Always"?
Only for features that genuinely need it, such as geofence reminders or family sharing, from apps you trust. When the system reminds you of background access, check whether you still use the feature.
How long is my location history kept?
It depends on who holds it. Google says Timeline is off by default, stores precise location on your device when you turn it on, and keeps it according to your auto-delete settings or until you delete it. Apps that receive your location keep it under their own policies, so check the privacy policy of any app you allow.
See how Safeguard would help
These demos show dependency workflows, not location settings. You can download Safeguard and follow the CLI docs to try them on your own projects.
This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. If you build the container image for a time server or a vehicle gateway, the same terminal scan can run against that image so the gpsd and chrony versions inside it are checked before it ships.
Click through it at your own pace, or open it full screen.
This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a location or mapping library in your app's manifest.
Click through it at your own pace, or open it full screen.
This demo is a real Android session: the phone sends work to a computer running the CLI and approves each command with Allow once, Allow for turn or Deny. It is the same per request choice a location prompt gives you, applied to the commands a coding assistant wants to run.
Click through it at your own pace, or open it full screen.
Quick check
Your time server uses a GNSS receiver that tracks GPS, Galileo and BeiDou. Is its time authenticated?
Not by default. Of those, only Galileo offers civil data authentication, through OSNMA on the E1-B I/NAV message, and only if the receiver implements and enables it. Even then, OSNMA authenticates the navigation message rather than the signal's arrival time, so keep independent time sources and alert when the GNSS reference is dropped or drifts.
Your Android app requests only ACCESS_FINE_LOCATION. What can go wrong on Android 12?
Google's documentation says the system ignores that request on some releases of Android 12 and logs an error when the app targets Android 12 or higher. Request fine and coarse together in one runtime request, and make sure the feature still works if the user grants only approximate location.
Sources
- GPS.gov: GPS overview
- GPS.gov: Space segment
- GPS.gov: New civil signals
- GPS.gov: GPS modernization
- GPS.gov: Selective Availability
- GPS.gov: Frequently asked questions
- GPS.gov: Other global navigation satellite systems
- GPS.gov: GPS and telling time
- GPS.gov: Spectrum and interference issues
- GPS.gov: Resilience through responsible use of PNT
- Federal Register: Executive Order 13905 (12 February 2020)
- CISA: Positioning, Navigation, and Timing
- EUSPA: Galileo
- ESA: What is Galileo?
- ESA: Galileo begins serving the globe
- European GNSS Service Centre: Galileo OSNMA
- European GNSS Service Centre: Galileo Open Service
- European GNSS Service Centre: Constellation information
- GLONASS Information and Analysis Center: About GLONASS
- BeiDou Navigation Satellite System: BeiDou-3 completion ceremony (31 July 2020)
- BeiDou Navigation Satellite System: Interface Control Documents
- ISRO: IRNSS Programme (NavIC)
- Apple Support: About privacy and Location Services in iOS, iPadOS, and watchOS
- Apple iPhone User Guide: Control the location information you share
- Apple Developer: CLAccuracyAuthorization
- Apple Developer: NSLocationDefaultAccuracyReduced
- Android Help: Manage location permissions for apps
- Android Help: Manage your Android device's location settings
- Android Developers: Location permissions
- Android Developers: Request location permissions at runtime
- Android Developers: Access location in the background
- Google Maps Help: Manage your Google Maps Timeline
Last reviewed: 23 October 2026. Constellation counts and signal status change often; check NAVCEN, the GSC status page and each operator's notices for the current figures.