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.

Thanks (and to Maarten too, for some reason I can't reply to his post) that explains it.

Nitro have made rather large claims; if they're real security experts then they need to share the details or GTFO.

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.