Static data for the entire system. A-GPS files are just a digital ephemeris[1], a form of trajectory tables for the satellites over (upcoming) time, so it knows when to expect certain satellites (and thus certain transponder frequencies to pick first in its search for signals to lock onto and triangulate from).
You can transfer a lot of information in a request, it's one of the oldest tricks in the book.
Whilst I also had a bad taste in my mouth once I got to them shilling their product (it was a double-check - wait a sec this Nitro phone they're talking about it's their own bloody phone?) that doesn't change the fact that this unexpected behaviour is a problem.
What we need to see is the actual HTTP requests, either from Nitro or - even better - from a third party who verify it.
Nitro's product also does it, but maybe they download the file from themselves or another vendor. Every internet-connected GPS device does it, and this has been the case since even before smartphones took off. If they don't, first fix in a day will take 10-15 minutes of solid reception.
Some GPS chipsets will perform A-GPS internally using a baseband IP stack, but most smartphones actually don't and expect a daemon to handle it since the OS has more sophisticated ways of deciding what network connection to use for the download. This is the most common case for Android, the OS downloads the file and uses a kernel module to provide it to the GPS chipset. The chipset vendors, including Qualcomm here, provide this service as part of their userspace components.
An IIOT LTE module I use has an onboard IP stack and AGPS implementation since it's intended for use in contexts where there isn't necessarily a conventional OS connected to it, maybe just a serial data logger or whatever. The A-GPS requests it makes contain so little data it's a bit comical, the bare minimum for a valid HTTP request. Another reason it's nice to have the OS do it is since that tends to get you access to a more complete HTTP library.
You don't need a third party, you just need to check your network traffic. The issue is that this request is not sent very often because this data is valid pretty long.
But it's basically just fetching https://xtrapath4.izatcloud.net/xtra2.bin with cron (or some other subdomain, depending on the SoC) and uploading that to the gps module so it has atmospheric corrections.
A-GPS provides a current almanac, showing where all the satellites actually are. Without it, a cold start requires hunting for signals across a much wider range. As I understand it, older GPS receivers rely on finding a single satellite and waiting to acquire a full almanac from it while smartphones have enough compute to probably get a lock on multiple satellites without a complete dataset. The satellites will eventually broadcast the complete almanac and ephemerides, so a warm start shouldn't take as long.
D-GPS uses the known location and current readings from a nearby fixed receiver to increase the accuracy of your receiver, and does rely on knowing that you're in the vicinity, but it's not a feature of consumer phones.
How would the server even know the client’s location? By IP address? That would make GPS work poorly when using a VPN or a wireless network with unusual routing.
edit: y’all are reading this backwards. My point is that the Qualcomm server does not know the location of the client and therefore cannot usefully send anything other than a static file.
The data isn't location based, it's the same for everyone. The GPS control center updates it once an hour or so, but it's applicable globally. As the article explains, GPS satellites broadcast it, but at a low bitrate so it takes a long time to receive. Much faster to just download it from the internet. Because of the architecture of GPS in phones (which is basically a historic artifact, the chipset is expected to provide NMEA sentences and the OS doesn't want to be more deeply involved than that) AGPS needs to happen at a fairly low level.
It's not that unreasonable an assumption. Qualcomm offers a different opt-in service under the same name that does use location data.
Basically your phone uploads sensor data like cell tower strength and WiFi strength, and their service estimates your location. The your device locally uses gyro/accelerometer to fine-tune.
In principle AGPS can send the GPS radio data to a remote server and have the server do the difficult maths then send back your position. This is apparently a thing somebody actually designed, however since "doing difficult maths" is now very cheap you'd obviously just do that on the phone.
[1] https://en.wikipedia.org/wiki/Ephemeris