/e/OS is not fully degoogled, as DNS connectivity checks, hardware attestation provisioning, and eSIM activation all go through Google.

It is often many weeks or months behind on security updates, especially in the WebView, which makes it easy to exploit.

It doesn’t support bootloader locking on many devices, and if you lock the bootloader on a phone that does support it, it could brick if /e/OS is on an older security patch than the stock ROM was.

It doesn’t use a lot of the hardening in GrapheneOS such as hardened_malloc which prevents memory corruption exploits, even if the hardware supports it.

And finally, /e/OS’s text-to-speech sends what you say to OpenAI, despite local options being available.

If you want a properly secure Android phone, the best option is GrapheneOS, however it only supports Pixel phones and future Motarola phones due to its high security requirements.

If you can’t get a Pixel then iOS in lockdown mode is the next best option, however if you can’t replace your phone, LineageOS is much worse than Graphene although it is still much better than /e/.

  • RmDebArc_5@feddit.orgEnglish
    1·
    12 hours ago

    Murenas statement on the ids used for OTA updates:

    For context, and I agree that this feature can be perceived with mixed feelings, especially because it was stupidly called „licence ID“ at the beginning of its implementation, we added it because we suffered from not having good statistics on /e/OS usage.

    Of course we are not interested in tracking users at all, but we do want to know how many devices are running this or that build of /e/OS. This is very useful for making some decisions about device support and setting priorities for future development.

    Just running statistics on OTA server request logs along with the device model didn’t give good results.

    Now, and this is still part of our internal discussions, if we are able to find a way to get good quality stats without this OTA anon-unique identifier, we will consider it.

    However, we sincerely believe that this anonID probably has no impact on user privacy (tracking IPs or device fingerprints would probably be much worse).

    You can reset the id via ADB:

    adb shell settings put secure ota_anon_hash <new value>