@GrapheneOS and anyone concerned with prospective security enhancements.
I'm at the evaluation stage in which I'm trying to figure out which "secure" OS to use with which phone. GrapheneOS caught my attention because it seems to offer most of the advantages of Android without the Googleware. I've been reading the forum here, trying to figure out what it does and doesn't offer. I'm encouraged to learn that it has certain features such as per-profile network access denial (which isn't a perfect exfiltration block but goes a very long way) and per-connection (whatever "connection" means) wifi MAC address randomization. (It's funny how my existing Android phone makes the same claim, but the MAC never seems to change. Untested crap!) However, there are some other features which it doesn't seem to include, which would be extremely useful. Your feedback is invited. Apologies if some of these issues have already been addressed, but I haven't been able to determine that in my limited browsing of the forum.
Warning popups on every attempt to enable location, WAN (i.e. airplane mode exit), wifi, or Bluetooth. (And definitely, all disabled by default on first boot, lest you accidentally tie the phone to your personal identity when you carelessly flash the firmware in your living room.) It's only too easy to tap one of these buttons by mistake. I'd want a dialog to come up asking me if I really want to enable one of these hazardous features. (People who don't want this could then check the "don't warn me again" box, or reenable the warning in the settings.)
IMEI randomization. Perhaps this violates ITU standards because in theory it would allow me to impersonate another user, but in the worst case, a dropdown with 100 of them from which to choose would be quite sufficient. It's also fine if I need to reboot in order for the changes to take effect. What's definitely NOT OK is being chained to the same IMEI throughout the life of the phone. That makes it super easy to track my location and know that "me" is the same "me" who hangs out "over there". Yes, this can all be done with traffic analysis anyway (even if it's all onion routed), but that demands a degree of intelligence competency that not all adversaries have. For example, various drug cartels are known to have installed their own base stations so they hunt their competitors, which is easily facilitated via constant IMEI. I suspect the answer to this is "We can't do this because it's the property of the baseband module". To which my response is "How might we hope to obtain a phone with a noncompliant baseband module and an OS IMEI override function?" Heck, even 2 baseband modeules, each with its own IMEI, would a marketable start.
Antenna timeout. This is the poor man's solution to the constant IMEI problem: I wish I could set a timer in the settings that automatically shuts down all antennas after some number of minutes (just like the screen lock timeout). It's a real pain to have to walk around holding my phone in my hand so I don't forget to enter airplane mode when I finish a phone conversation. It would be more convenient to keep it in my pocket but not have to worry that I might forget, and end up taking a 5G tracking device back home with me.
Location spoofing. It would be nice to freeze my location at the hotel long after I've checked out. Some apps apparently check for movement, so adding a bit of dither over time would help. Ideally, I'd want location recording and looped playback (but that's major so I don't expect it). Just disabling location isn't always good enough because certain apps refuse to function under such regimes. So like: location on, off, or frozen and dithered.
Location timeout. Same thing as antenna timeout but for autodisabling location (or entering frozen dither) after so many minutes.
Wifi environment blocking. I think GrapheneOS already does this, but I haven't been able to find any specific guarantee. In other words, I don't want any app to know the SSID to which I'm connected, or any SSID in the vicinity (which is a proxy for location).
Local IMEI and phone number blocking. Can I prevent apps from learning this information? Probably, but I'm not sure how. (For example, Google lets you create some fixed number of accounts per year, per phone. How are they enforcing this? Maybe they don't send your IMEI to their servers, but either way, they're obviously tagging the phone.) Ultimately, it's all but impossible to prevent apps (or profiles, in the broader sense) from fingerprinting your phone. But cutting off access to these variables (or providing random values every time) would be a step in the right direction if that's not already the case.
Bluetooth ID customization. I'm no expert on this, but it seems to me that Bluetooth entails a device descriptor string, a connection PIN, and a MAC. Being able to change all these would be helpful. However, I realize that apps would need access to the names of connected devices so for example a blood glucose monitor app knows which one to talk to. The most rigorous implementation would allow me to specify which individual devices a given profile could know about.
This isn't a feature, as such, but it would be nice to have a guarantee somewhere (maybe already in some doc I'm unaware of) which says that airplane mode means: (1) You don't get any 5G emissions, ever. Not when you reboot. Not when you patch your OS (which iOS violates upon every major version number upgrade, rebooting with the antennas blaring). Not on the way to a power down (not even if "send last location" happens to be enabled). No IMEI leakage due to baseband module testing during powerup or powerdown. No single-bit pings. No WAN photons, period. (2) Turning it off only enables WAN. It doesn't do the nutty iOS thing of enabling wifi or Bluetooth when you exit it. But it's fine if wifi and Bluetooth get disabled as a side effect when entering the mode, which could come in handy when one wants to silence the phone ASAP.
I realize that GrapheneOS is freely available, and as such, we can't just expect things to happen even if the team itself wants them to. My goal here is just to provide some prospective features to contemplate adding in the future (or to be rebutted because they already exist in some way).