Qualcomm chipsets data collection linked to the A/GPS service in /e/OS

/e/OS Foundation & Community Announcements
1

In a recent blog article that made some buzz, some concerns have raised about potential personal data collection in some Qualcomm chipsets used in popular smartphones running /e/OS.

When discovering this post today, we’ve been suprised to discover its content because the facts that are described there are not new, and because we’ve not been contacted by the author before publishing, which would have been a more constructive approach.

So let’s discuss the points that have been raised:

1- Connections to [2022-05-12 22:36:34] android.clients.google.com

This is linked to the OS registration against google servers, which is needed by microG to enable push notifications. This has been explained in the past:

2- Connections to izatcloud.net

Those calls are triggered by some Qualcomm GPS chipsets to improve the GPS location service. The service in question is called A/GPS and is using the SUPL protocol. More information at: https://en.wikipedia.org/wiki/Assisted_GNSS

Are those calls legit? Yes. Those are well known protocols, well described and described in Qualcomm public documentation.

Are those services common? Yes. Qualcomm, Mediatek have it, probably some other chipsets use similar protocols as well.

Do this service process personal information? Yes. In most case it will send at least the device’s IP address, some location information and possibly other data in some case (device id…), which are considered personal information.

Is it legal? Probably not legal in the EU without users’ explicit user’s consent. Under the terms of GDPR, it would need user’s prior approval. We will investigate about this to figure out if and how it is possible to implementation an explicit opt-in for this service for /e/OS EU users.

Is it problematic? Yes and No.

Yes because it is likely sending some personal information to Qualcomm, and we have no certitude what they are doing with this information.

Yes because it’s probably not legal in regard to the GDPR without explicit user consent.

No because it’s generally a limited set of information (IP address, location…) and it’s unlikely used by Qualcomm to track users and make some business from it. It could be used to track targeted people though, on a government request.

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. …?

Stay tuned.

Gaël

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

26 Likes
2

Thank you for your detailed answer.
I just want to point out an actual research of Mike Kuketz, a well known German security researcher. He is writing a series of articles about custom ROMs (article in German). He already investigated about Graphene, Calyx, Iodé and LOS, and will soon have a look at /e/ too. He is absolutely serious, and I think you should watch out for his research and take his conclusions into consideration.

Thank you and your team for all this work!

5 Likes
3

Thanks @fab …another regular user had shared this information some time back. We always welcome positive comments and feedback that is used to improve /e/OS code and services.

4 Likes
4

Awesome, thank you very much! When I saw this “news” today, I though it was strange that there wasn’t an alternative beside using a device without qualcomm.

5

Hi Gaël,

Thank you for reacting on this albeit this is old news for some of you. For me, it is new, although I had in mind that the binary blobs you (all de-google developers) are required to use, pose a threat to the paradigm to own your data and your device.

Some time back, i fumbled with the IPMI protocol and hardware devices that enables managing a computer externally (out-of-band) over the same PHYsical network interface that the OS uses.
Is this a comparable technology? If it was, how could you influence the data sending behaviour from the inside?

If it is not, all options you name seem valid use cases. I, personally, would use option one anytime, since i do not care about my phones location.
Option three does not take into account that the remaining data is still able to feed a tracking database.

How about option two using a load balancer on the server side? For users it looks like a proxy supl server, but for the real supl server you needed several servers to avoid being blocked.
You could set this up in collaboration with graphene, calyx, iode and lineage.

I did not pay for and have a service agreement with qualcomm or even fairphone or any hardware manifacturer, i have an agreement with e/-os/murena if at all.

I would rather pay for a service like that with money than with data, even on a per-use basis. Others may find this should be a free service to the privacy-concerned public.

You could also have a fallback to the data-paid supl service if you supl-proxy went down/were blocked and ask the user with the appropriate warning.

Three more comments:
The community probably has to verify the behaviour for all non-qualcomm chipsets.

How possible is it for other hardware components to start chatting with unwanted third parties?

Last but not least, new /e/-os users should be informed, even if this illegit behaviour of the phones hardware is not your fault.

Cheers, Tobias

6

The blog post cites a statement from Qualcom that includes the following:

We may also obtain personal data from third party sources such as data brokers, social networks, other partners, or public sources.

If they only used it to provide the service and have some statistics, there would be no need to cross-reference it with data like that. It seems extremely likely that they do something else with it.

Combined with third-party information linked to the same IP address, we are no longer talking about “a limited set of information”, it is enough to uniquely identify an individual and find out a lot about them.

Even if this is exclusively intended for Five Eyes government spying, the fact that:

  1. the data is not encrypted and can be collected by any entity with access to the network infrastructure (including Chinese networking hardware, European governments, private data collection companies that have contracts with network operators, anyone on your favorite café’s WiFi hotspot…).

  2. the possibility that the database at Qualcomm may get stolen or leaked and subsequently sold or published on the internet at any time

makes this a privacy risk that should probably not be taken lightly.

Except for these use cases, there is no justification whatsoever to transmit individual chipset serial numbers, subscriber IDs, lists of installed software (which could reveal political affiliation, gender, medical conditions, nationality, relatitionship status, which bank the owner uses …), or even when, how often, and where they charge their phones.

Anyway, I really appreciate the timely update on the matter and I’m looking forward to the solution the /e/ team will come up with. I agree with @Tobias, this seems like a good opportunity to collaborate with other projects like iodé, Graphene etc. to avoid duplication of effort.

3 Likes
7

Regarding 1) have you considered implementing an OpenPush service as part of your Nextcloud offerings instead of supporting Google’s push notification service?

https://unifiedpush.org/users/distributors/nextpush/

1 Like
8

Sure. Then we would just have to convince all mobile apps publishers to add this push option into their app.

5 Likes
9

I would still like to have that option for those foss apps which does support unified push. Sure, it’s unlikely it will be at all apps but having option to use that for some would still be nice and help some foss apps which are delivered from f-droid.

About supl, could /e/ use supl.grapheneos.org or have it’s own supl.murena.io at some day? I think this would at least help to remove some fuzz around this and be seen as positive sign, regardless how big issue one think it might be. Benefits could still be bigger as reputation wise when reports like this comes out.

1 Like
10

Qualcomm collects huge amounts of data.

11

This problem observed 2 years agoe. People saw some tracker block list blocking these izatcloud.net domains. But the blocking caused GPS problems. Allegedlly enough to allow them sometimes, to let the A-GPS work.

Qualcomm gathers a huge amount of user data.

Issue
Requests from these domains are needed for people that use their GPS. I had many GPS issues and didn’t find how to get rid of these… After noticing that these domains were making requests each 5 min, I found why I experienced these issues : A-GPS data was not updated at all.

What data is really collected ? Qualcomm official’s website answers

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.

https://github.com/jerryn70/GoodbyeAds/issues/160

2 Likes
12

Maybe it is just a matter of asking the users during the installation, if they want Assisted GPS or not? Users who really care about privacy would say no, and that is maybe acceptable. I mean, even without A-GPS, GPS still works. Sure, a fix is going to take 10+ minutes, but then you will have it, and you can keep it on all the time if you want. Also, services like the mozilla location service can help your device figures out where it is, without A-GPS. I don’t remember if it’s already available in /e/.

1 Like
13

Hello,
I thought that Mozilla UnifiedNIp Backend / Mozilla Location service was specifically used for A-GPS quick pre-fix without relying on other proprietary services with bad privacy.
Mozilla UnifiedNIp Backend is set-up by default on all /e/ os.
Do we know if exynos CPU are doing the same as Qualcomm ?

14

No. It uses the network.

20230505_011826
20230505_011826592×1024 89.5 KB

1 Like
15

Not necessarily. I care about privacy, but I am also happy that the phone use SUPL and AGPS.

In my opinion (based on quite a lot of reading, of both white papers and source code) the information sent to the SUPL Location Platform (SLP) in the network does not seriously compromise my privacy. I realise that that data could - in certain circumstances - be be misused by a 'bad actor`, but I am not aware of any instance where it has been used in that way. So, for me, the advantages (faster location detection, in both normal and emergency use) outweigh any theoretical risk to my privacy.

Others may have a different opinion about the balance between privacy and utility :slight_smile:

5 Likes
16

After some readings by myself, I totally agree with you @petefoth .