Connections to izatcloud.net

Hi,

I am using /e/ on an Fairphone 3 (bought directly from /e/) since two months.
Since six weeks I use Blokada to block trackers.
The first five weeks the log was nearly empty, because I use only Apps without trackers. So only some website trackers like google analytics have been blocked.

But since one week the log is full with blocked requests to
xtrapath1.izatcloud.net
xtrapath2.izatcloud.net
xtrapath3.izatcloud.net

It seems not to be related to an app. In Blokada I sadly cannot see which app or part of the system makes these requests.
So I tried also Netguard, and there I see only apps and no app tried to reach izatcloud.net.

In other topics I found out that it possibly has to do with a Qualcomm GPS chip “calling home”?
Sometimes there are many many tries during one hour. And then for some hours zero. GPS on or off makes no difference.

But why does this happen since one or two weeks and not before?
And what is the reason?
And is there a way to stop this (completely, not only by blocking)?Screenshot_20200725-105159_Blokada

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

yes, you will get this on every rom. Izt’s from QUALCOMM. And the number will count upwards for every blocked number.

Thanks for the info.

Does anybody know what Qualcomm’s going to do with this?

Or if it would be critical if it wasn’t blocked?

I would block it and see if something is broken.

blocking makes no problem. But you have to block it global *. izatcloud.net.

Ok, thank you. I have it globally blocked and everything works without problems.

This is used to download the data for AGPS (so the GPS will get a faster fix) - not to be confused with all the UnifiedNlp and the like - network location services.

It is in fact kind of scary and ominous, even if there is SOME information on internet about it not many are doing anything about it. This is leaking A LOT of data to Qualcomm by design: https://www.qualcomm.com/site/privacy/services :

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

The data they don’t mention is also your IP (which I’m sure they log) and what’s more is leaking this data to anybody listening as it’s plain http (for WiFi the access point can identify you even if you use randomized MACs, anybody who’s listening from other WiFi clients, etc).

There are also attacks possible, at least denial of service by serving you other files (possible without https).

It is also worth noting that a Android VPN/firewall might not protect you as this likes to call the mothership at each boot. Also some said it might be doing the same over the 3G/4G data network without help from the OS, therefore bypassing completely any firewall we can throw on it (and making it actually very complicated to sniff to even prove it’s transferring data that way).

1 Like

I think this should be fixed in /e/, at least the part that comes from normal user-space and it’s compiled and delivered in /e/ ROMs (even if it’s from some /vendor/ part of the source tree). Whether the baseband processor is doing something behind the scenes and calling home is something else to worry about but at least what /e/ OS does should be “right”.

Alternatively at a minimum /e/ should include in the license conditions that this software it’s sharing (quite a bit of) data with Qualcomm but I’m pretty sure this isn’t the desired path.

1 Like

One can easily change that behaviour by changing the gps.conf and let that point to another server serving the same file.

The request looks like:

109.42.112.218 - - [31/Dec/2020:15:14:44 +0000] “GET /xtrapath1.izatcloud.net/xtra3grc.bin HTTP/1.1” 200 27226 “-” “Dalvik/2.1.0 (Linux; U; Android 10; SM-N9005 Build/QQ3A.2
00805.001)”

in apache logfile. It still needs some investigation if in some headerfields more information are transmitted, the request is a simple GET, so no additional data was send.

AGPS is a real speedup so maybe this proxy-like aproach is a solution to provide the service and some privacy?