[dchest]

The author didn't address the list of things the devices allegedly sent when downloading A-GPS files, from the original article:

1. Unique ID

2. Chipset name

3. Chipset serial number

5. XTRA software version

6. Mobile country code

7. Mobile network code (allowing identification of country and wireless operator)

8. Type of operating system and version

9. Device make and model

10. Time since the last boot of the application processor and modem

11. List of the software on the device

12. IP address

[not2b]

The author claims that none of the above information is actually sent, other than the IP address which is unavoidable to download a static file. I don't know who is right because I haven't seen the actual intercepted HTTP traffic.

[iudqnolq]

It is odd that neither article quotes from the policies linked from the domain they're talking about.

I think the relevant section is "Qualcomm GNSS Assistance Service" on https://www.qualcomm.com/site/privacy/services

> The Qualcomm GNSS Assistance Service downloads to your device a data file from QTI containing the predicted orbits of the Global Navigation Satellite System (GNSS) satellites. The Qualcomm GNSS Assistance Service also uploads a small amount of data to us comprised of: a randomly generated unique software ID that is not associated to you or to other IDs, the chipset name and serial number, the Qualcomm GNSS Assistance Service software version, the mobile country code(s) and network code(s) (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the date and time of connection to the server, the time since the last boot of the application processor and modem, and a list of QTI software on the device.

> As with any internet connection, we will also receive the IP address the device used to send us data. We use the data we collect to evaluate, maintain, and improve the performance of our systems and to determine general location (but not specific geolocation). We do not sell (as that term is defined under the California Consumer Privacy Act) the full IP address, unique software ID, or chipset serial number, and we share personal data only under the limited circumstances described in this Policy.

[amluto]

> the chipset name and serial number

That’s actually pretty damning. A bunch of (chipset serial number, IP) pairs can track users very effectively over time. And saying they don’t sell the serial number or IP is mostly worthless — they could easily sell equivalent information.

[not2b]

I didn't ask about what the policy document says, but about what is actually transferred by the chip itself, independently of the OS. Since it's not encrypted this can be determined.

[iudqnolq]

Okay but I don't see why you're so skeptical of the policy.

This is all normal telemetry data roughly analogous to what most websites collect. Why are you assuming they're probably collecting much less?

[admax88qqq]

Because policy documents are written by lawyers to cover the companies ass for every eventuality. There is a different motivation here.

The code is written by engineers to either solve a problem, or spy on the users. The policy document does not disambiguate between the two.

[AdamJacobMuller]

Especially because the service required to capture/collect these metrics would be several orders of magnitude more complex than the service required to serve a single static file.

[MartijnBraam]

That's not a list of things allegedly sent. That's a list the lawyers put in a legal document to not get sued in case it happens.

[flas9sd]

a-gps/supl ("xtra"?) and qcoms izat api (in-building location services using indeed accesspoint info) are mixed in both HN threads. If izat triggers in customroms and sends plain http needs to be shown, but the .so libs are on device firmware partitions if not actively deleted. On older devices lineage mounts them unmodified from stockrom into /vendor/