Cellular provider identification of GrapheneOS usage

User19091

I am hoping the group here can help me answer a couple of questions regarding the use of GOS within certain authoritarian countries that may scrutinize users based on GOS usage. While I understand that one can modify their sever checks on GOS to mimic standard android devices via pinging Google servers, I do not know how the behavior of the device looks to the cellular provider. For instance, if I run the device with VPN always on and server checks set to standard google servers, can a cellular provider determine which OS I am using based on the interaction between the SIM card and the OS? If the OS cannot be determined, how different does GOS look compared to stock Android? In this scenario, it is assumed that the user is using minimally invasive apps, relying heavily on browsers for any service requiring a login.

The threat model is wanting to maximize privacy and security of the device (hence GOS) while avoiding unwanted attention from potentially unfriendly governments (https://xkcd.com/538/). I am trying to figure out if using this OS would make someone a target just based on the connecting to the cellular network, which as we know should not be trusted. I am not concerned with the cellular provider knowing the name/location of the user, but rather having their identity tied to GOS usage. Ultimately, some populations like aid workers/NGOs may need to forgo some privacy and security to be permitted to do their jobs in certain locations.

I strongly believe in what this project is doing. However, if using GOS in this scenario is unsuitable for whatever reason, I would appreciate your recommendation for a different OS that may be more appropriate (or recommendations on using stock iOS/Android with modified settings). I appreciate any insight the community may have.

zzz

User19091
3x thoughts:

2- It might depend on your carrier.
For example, if your carrier requires installing an app:

Apps can detect that they're being run on GrapheneOS via the privacy and security features placing further restrictions on them and hardening them against further exploitation.

https://grapheneos.org/faq#non-hardware-identifiers

3 - An anecdote from my experience:
Anecdotally, I can share that a US carrier could tell that something was "off" with my GOS Pixel phone just by inserting a SIM card and activating service on their website (which required a disabled VPN).

In the online portal of my carrier account, there was a page listing devices that share the plan. The devices were displayed in a list including the model number, a thumbnail image of the phone, phone #, and some other metadata, My GOS Pixel phone was the only one conspicuously on the list lacking a thumbnail and some other fields, compared to the other iphones and stock androids (including a stock Pixel) on the plan which did have thumbnails and more metadata reported.

It wasn't a problem for getting service with that carrier, but I think it was a problem for me ~ 1 year later when trying to transfer my phone # to a new account with the same carrier.
I ended up spending ~ 6 hours on the phone with various support people who didn't understand why there were mysterious backend issues with transferring my phone # to a new account. I never told them it was a GOS phone, and they never identified an alternate OS (let alone GOS specifically) as being present, or being the problem. They could never identify a plausible explanation at all, in fact.
I finally resolved the issue at a retail location where they begrudgingly gave me a fresh SIM card, then transferred my phone # and account to the new SIM, and it cleared up the issue.

All that is to say, I suspect it's not hard for a carrier to tell that something is unusual about a GOS phone while using their SIM or eSIM.
Whether or not that level of unusualness is known by the carrier to be specifically GOS, or even specifically an alternate OS, probably depends on their level of sophistication.
In my anecdotal case, the typical customer portal tools and customer support employees were not able to identify my phone as having an alternate OS or GOS, but my device did stick out as unusual in fingerprinting and backend technical ways.

Hope this helps. Would love to learn more about this as well.

de0u

User19091 Ultimately, some populations like aid workers/NGOs may need to forgo some privacy and security to be permitted to do their jobs in certain locations.

Yes.

If it would be a concern for a carrier to know that a phone is running GrapheneOS, wouldn't it also be a concern for police officers (etc.) to know, which would probably happen in the course of time?

It might be best to use a completely-standard device and to place no trust in it. The alternative, trying to carve out an enclave of resistance to an authoritarian regime, seems like it will always be at risk of discovery.

User19091

zzz

I appreciate you sharing your experience. I suppose that does make sense given the following from the features list:

"We convert their APN, carrier configuration, MMS and visual voicemail databases to the formats used by AOSP with our CarrierConfig2 project and scripts. We strip out anti-user configuration requiring provisioning for tethering, forbidding disabling 2G, etc. We don't include the invasive carrier-specific apps and support for Open Mobile Alliance Device Management (OMA DM) so we also strip out configuration depending on those."

And then from the cellular usage guide: "GrapheneOS includes bypasses for carrier restrictions on APN editing, tethering via USB, Ethernet, Bluetooth and Wi-Fi and the ability to disable 2G (only on 6th generation Pixel devices onwards) actions which would not necessarily have been possible on the stock operating system"

I wonder if it is possible to toggle some of this functionality in a granular way similar to what we are able to do with the network permissions , etc. I also wish I had the technical background to understand what is happening on the back end with these processes. That would probably allow me to ask better or at least more particular questions.

De0u, I agree with you completely. It's a shame we have to give up our privacy in these instances.

de0u

User19091 I wonder if it is possible to toggle some of this functionality in a granular way similar to what we are able to do with the network permissions , etc.

In theory, yes, but, aside from the work to write and maintain the code, more toggles would mean more ways for a device to act differently than a regular device for that carrier.

There is fundamental tension between giving a user more control over a device and giving a carrier more control. Some carriers don't care, but tricking the ones who do isn't really feasible.