If you're a GrapheneOS user, it's worth being aware of the consequences of revealing device identifiers, which give away privileged device info, effectively fingerprinting your phone permanently. Much of this is tied to RCS as it stands today.

Firstly, whatever SMS/MMS/RCS app you set as your messaging app will have access to

READ_PRIVILEGED_PHONE_STATE

which the official FAQ notes, regarding the messaging app, is a

...special case that's given access to certain device identifiers including the IMEI. This is normally the GrapheneOS fork of AOSP Messaging but can be changed to another app by the user.

This means that even if you change your messaging app for one moment with network access, that app can (and will) utilize that IMEI and any other identifiers that the privileged state allows. This is a necessary evil of carrier-based messaging.

Secondly, if you've settled on using RCS, which is currently only implemented through Google Messages, it's worth noting, as GrapheneOS devs say,

Some carriers use a verification method (GSMA TS.43) that requires Google Play services to have the permission to do ICC authentication with device identifiers.

This is done by visiting your settings, apps, Sandboxed Google Play, Play services special permissions, and enabling 'Allow ICC authentication with device identifiers'.

Currently, it's obvious that if you're using Google Messages, your only immediate RCS option, that enabling this toggle is not really leaking much additional data since you already spread 'dem cheeks to Google. Again, your carrier already knows a bunch, but that's the price of using modern telecommunications infrastructure. However, by enabling this setting, Google Play Services is also allowed the privileged state mentioned earlier.

If you must have RCS right away, then you're SOL anyhow. But in the future, GrapheneOS devs are planning to attempt their own RCS implementation that doesn't rely on Google (sorry I am not linking to the direct Twitter post). If/when this comes to fruition, RCS will be possible without relying on the infrastructure Google has so thoughtfully trapped us with set up for us.

If you can wait for that day to come, then you should wait for that day to come. Because if you really want to keep Google from having privileged info, you need to know that allowing it now and disabling it later is in part, though largely pointless because the consequences of the decision you made prior are permanent, in relation to identifiers leaked, so long as any of those identifiers remain the same.

Additionally, Google Play Services can communicate with other apps even without networking via an Android feature called inter-process communication (IPC). This allows apps designed for it to communicate directly with each other, in this case Google-to-Google. This includes apps that utilize tracking/analytics through things such as Firebase Analytics. That's a LOT of non-FOSS apps.

Though it's not proven what exactly Play Services exfiltrates via IPC, you don't need to be Sherlock Holmes to deduce that there may be foul-play involved. Maybe you have an app that is made by Google or uses Firebase that you keep network off for - if you allowed Play Services those ICC permissions, you are, at least in theory, creating a pathway to leak data you may not have intended.

There are a million more ways you might be giving valuable and private and identifying data to Google, but this is one I see often overlooked because RCS is the easiest way to enable encrypted communications with those who don't use any purpose built app such as Molly/Signal or SimpleX Chat etc.

For those wondering, "can't we configure IPC like with other permissions?", great question, you might wanna check out this forum discussion (amongst many others). For those wondering why RCS is so seemingly Google-dependant, check out the wiki page on RCS for some fun history on how Google fucks with everything and everyone on earth.

Caveats:

• If you're running older Android =<10, check the FAQ more cause idk much about that.
• There are things such as Openbubbles that serve a specific niche with different risks/benefits that I'm not covering here. The tech behind it is also very different.
• I'm not a GrapheneOS dev, don't take my word for things, check out the official forums and Github for more in-depth discussion.
• Things can change quickly and unpredictably. Make sure the reality still matches as of this post's date.
• Your decision to use Google on GrapheneOS is not wrong, and it's up to the individual to determine their boundaries or what they deem acceptable.
• Google IPC data exfilfration is not proven fact, maybe a heart still beats within the company somewhere, lol.
• Google doesn't literally fuck everything and everyone on Earth - yet.
• There's subtleties lost here and details simplified, but the overall point is not lost. If you're interested you should read more about it all, it's fun to learn about!