Final on Nostr: No and yes. It can't be done directly through the OS and requires convoluted ...
No and yes. It can't be done directly through the OS and requires convoluted processes such as debug features and tampering with non-persistent state but it provides little overall value that avoids the solution of dealing with a hostile network like it which is not using that network at all. High risk users should just stick to WiFi and not use a SIM. Airplane mode prevents tracking from cellular by disabling the cellular radio. Such identifers usually aren't visible to apps in the OS unless they have READ_PRIVILEGED_PHONE_STATE, so system apps. The default SMS app is a special case that's given access to the IMEI, which is normally the GrapheneOS fork of the AOSP Messaging app unless users explicitly change it to another app at their own discretion.
We had been asked about it and clarified back when old Snapdragon Pixels could do it. Exynos Pixels could, but it's a no at this stage and had been for a long time It's nothing like WiFi MAC address randomisation.
Changing IMEI wouldn't prevent tracking via cellular since there are other identifiers specific to radios and also extensive fingerprinting possibilities. Choosing a random IMEI while everything else being the same as before would make you almost entirely unique as a starting point. It will only hide one commonly used ID rather than making the device not uniquely identifiable.
Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities or features they support. The general type of radio/device is extremely obvious to the network since a bunch of capabilities, configuration, etc. vary and are directly reported to the network. We try to match stock Pixel OS configuration but it's clear it's a Pixel based on network behavior and not just an arbitrary number.
Identifying yourself to the network is what a SIM implements so you inherently get identified as a specific subscriber based on that too. You could change SIMs often but that's costly and doesn't solve the above problem. The radio is also supposed to send a unique identifier and will often send other identifiers, including but not limited to EID when using eSIM.
Since IMEI is typically configurable by OEMs building the phone and often has a debug feature for changing it, it can end up being possible to change it. It's a mistake and typically comes along with vulnerabilities. Reporting upstream could come with rewards but we're not looking into it. If upstream patches it, its no good for us then...
GrapheneOS only generally reports to Google if the vulnerability is major, exploited in the wild and/or their input to patch is required to protect the devices we support. Last major example of when we did this was for vulnerabilities exploited by a forensics firm selling a password brute force exclusively for the stock OS. While not affecting GrapheneOS the response and firmware changes helped us greatly in implementing duress password.
I also haven't counted RF fingerprinting (affects other radios too) or tracking miscellaneous artefacts like mobile data web traffic (conditional) or direct connection to the provider's IPsec tunnel for WiFi. RF fingerprinting two of the same mobile devices is a common academic project and you can check them out online.
Uninformed users would be fed false hope and act in ways they shouldn't with the feature which could endanger them. There is no legal restriction holding the project back, it's the above reasons.
We plan to provide more configuration for controlling Wi-Fi calling/texting where users can entirely toggle off the IPsec tunnel it uses while still using the SIM. It's not one of our top priorities since disabling the SIM is already available as a standard option and does that.
We had been asked about it and clarified back when old Snapdragon Pixels could do it. Exynos Pixels could, but it's a no at this stage and had been for a long time It's nothing like WiFi MAC address randomisation.
Changing IMEI wouldn't prevent tracking via cellular since there are other identifiers specific to radios and also extensive fingerprinting possibilities. Choosing a random IMEI while everything else being the same as before would make you almost entirely unique as a starting point. It will only hide one commonly used ID rather than making the device not uniquely identifiable.
Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities or features they support. The general type of radio/device is extremely obvious to the network since a bunch of capabilities, configuration, etc. vary and are directly reported to the network. We try to match stock Pixel OS configuration but it's clear it's a Pixel based on network behavior and not just an arbitrary number.
Identifying yourself to the network is what a SIM implements so you inherently get identified as a specific subscriber based on that too. You could change SIMs often but that's costly and doesn't solve the above problem. The radio is also supposed to send a unique identifier and will often send other identifiers, including but not limited to EID when using eSIM.
Since IMEI is typically configurable by OEMs building the phone and often has a debug feature for changing it, it can end up being possible to change it. It's a mistake and typically comes along with vulnerabilities. Reporting upstream could come with rewards but we're not looking into it. If upstream patches it, its no good for us then...
GrapheneOS only generally reports to Google if the vulnerability is major, exploited in the wild and/or their input to patch is required to protect the devices we support. Last major example of when we did this was for vulnerabilities exploited by a forensics firm selling a password brute force exclusively for the stock OS. While not affecting GrapheneOS the response and firmware changes helped us greatly in implementing duress password.
I also haven't counted RF fingerprinting (affects other radios too) or tracking miscellaneous artefacts like mobile data web traffic (conditional) or direct connection to the provider's IPsec tunnel for WiFi. RF fingerprinting two of the same mobile devices is a common academic project and you can check them out online.
Uninformed users would be fed false hope and act in ways they shouldn't with the feature which could endanger them. There is no legal restriction holding the project back, it's the above reasons.
We plan to provide more configuration for controlling Wi-Fi calling/texting where users can entirely toggle off the IPsec tunnel it uses while still using the SIM. It's not one of our top priorities since disabling the SIM is already available as a standard option and does that.