Ah, I didn't manage to recollect your mention of NextDNS in your post. There's no need to change anything regarding your DNS settings in such a case; it won't take much of your battery.

Here's a related discussion on the /e/OS forum: https://community.e.foundation/t/qualcomm-chipsets-data-collection-linked-to-the-a-gps-service-in-e-os/48982. Note that the domain mentioned in the discussion is izatcloud.net, however, for your purposes you can consider it the same as the domains you're seeing.

What can /e/OS do?

The SUPL-A/GPS case is well-know for a long time. Though it’s probably a low impact case in term of user’s privacy, we are evaluating how to prevent or mitigate it in /e/OS.

Options we have today:

1. Block SUPL requests using /e/OS’ Advanced Privacy tracker control. But that would probably kill the A/GPS service, making the GPS location service very, very slow.
2. Proxy SUPL requests to anonymize their originr. That’s an option but it can be blocked if we send too much traffic to the SUPL servers. This would likely happen because /e/OS has a lot of users, and would have an impact in term of service continuity.
3. Figure out how /e/OS users can use Advanced Privacy IP scrambling features to fake SUPL calls origin IP address.
4. …?

You might want to try option 1 and check. Please revert back to this comment after attempting to do so, so that others can benefit from this idea.

XTRA uploads the following data types: a randomly generated unique ID, the chipset name and serial number, XTRA software version, the mobile country code and network code (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the time since the last boot of the application processor and modem, and a list of our software on the device

They just forgot to mention that this data is sent with no encryption (except in the xtra3grc.bin format, hope that they’re exclusively using that now…). Of course it should be blocked. But it’s necessary to allow one of those 3 domains in order to make the GPS work properly.

And here's the Wikipedia article on what is it that the Qualcomm chip is trying to gather: https://en.wikipedia.org/wiki/Assisted_GNSS

Just a heads up - Been following UT for some time and the major for me is that there is currently no VolTe support. Major bummer for US folks. There's workarounds, at least for pixel3a but its not 100% reliable.

Also SMS / MMS can be troublesome as well. Can't download images while on WiFi??? Group MMS doesn't work.

Great system, works well but I can't make it my daily driver

I think unless the HAP bit is specifically set to 1, Intel ME is still active on consumer boards, just without an interface for the OS to interact with it. Not sure if someone has hacked an OEM UEFI/BIOS to interact with it, but I have seen a different MAC address from my PC on my network before, and this is without any virtual adapters. This is the only explanation I can come up with.

For what it's worth, I did specifically say ecosystem because the TPM is just one component, which is required to authenticate the remote wipe. Also the drivers are installed automatically with most modern operating systems, it's not like you install your own south bridge driver, for example. Linux of course notwithstanding.

I've seen it used successfully numerous times. Someone steals one of our laptops, rips the drive out, installs vanilla windows, and boom it reboots and performs a wipe.

Regardless, system-on-a-chip are just that, systems; they can absolutely make remote calls without user interaction, just as intimated by the comment you originally replied to.

"Just"