I’ve used both iodé and graphene is over the past year and have some suggestions to make iode compete better with GrapheneOS in terms of security.
Would it be possible to implement a Duress password that wipes the device when it’s entered?
And maybe implement something similar to Graphene’s Storage scopes and Contacts scope.
I’m not saying iodéOS sucks. In fact, iodéOS beats GrapheneOS in terms of user features (e.g. GrapheneOS lacks VPN for hotspot, ability to use custom server for NLP and cellular location and their screenshotting sucks ).
I just wish it could be a bit stronger with security, especially on Pixel devices which already provide a secure hardware. It’ll be nice to have a microG alternative to Graphene’s hardening.
As always, I thank the devs for their hardwork maintaining an OS without having Google’s money
Thanks for the inquiry, do you know how Pixel-specific the patches are to enable a Duress pin? One thing Graphene can certainly do better than iodé (due to a much larger development team plus a very limited number of devices to support) is dig into the specific device builds to make such hardening adjustments.
I think it is fair to say our primary focus is increasing privacy by reducing tracking via our integrated blocker and by reducing reliance on proprietary bits (microG instead of sandboxed “full fat Google Play Services”). But deep customization per device is a bit beyond our (current) scope.
The common phrase you may see is “Graphene for security, iodé for privacy”, which is a bit of a misrepresentation of both projects. Certainly Graphene also is extremely strong on privacy, and certainly we consider ourselves also strong on security (no adb root, relocking bootloaders whenever the device allows it, monthly security updates, etc.). But us not having capacity to only focus on newer Pixels (and maybe 1 Moto option in the future) means we won’t be able to match what a custom security hardening focused large development team can offer.
In addition, another core iodé value is that device longevity extends much beyond manufacturer support timelines. We do continue to release monthly system updates (including any OS level security updates) for devices still stuck on devices with Android 11 bases(!) but this would be not be considered the “secure” thing by true “security hardening focused projects” since there are no firmware updates provided by the manufacturers anymore, but we feel it is an ecological priority and is important to keep doing.
It may be “generic system software level” only, my point is I don’t know either. But if it is hardware dependent then it gets much more difficult to implement across our broad range of supported devices.
I’m not sure how much change this would need in the code base, but maybe kind of a short cut into “factory reset if pin entered wrong 15 times “ setting?
Edit: Probably something for “feel free to create a pull request “.
).