I started reading and thought that it isn’t that bad, just what I expected from closed source software but then came this:

Team Memory Sync, an unreleased internal project. There’s a bidirectional sync service (src/services/teamMemorySync/index.ts) that connects local memory files to api.anthropic.com/api/claude_code/team_memory. It provides a way to share memories with other team members within an organization. The service includes a secret scanner (secretSanner.ts) that uses regex patterns for around 40 known token and API key patterns (AWS, Azure, GCP, etc). But sensitive data that doesn’t match these regexes might be exposed to other team members through memory sync.

This seems like a great idea!

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>

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

They are working on some of this, at least eSIM activation. Also do you have a source for DNS connectivity checks? AFAIK they have used their own for a while

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

This is a serious problem, however their update speed is comparable to a lot of default ROMs

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

/e/os supports boot loader relocking on most official devices, however the community builds don’t support it. The bricking part has nothing to do with /e/os, it’s a hardware security feature of some devices. This would happen with any ROM including the official one

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

I assume you mean speech-to-text? Anyway the feature is opt in and they have since updated it to include a prompt to inform you about what it will do. Their reasoning for a cloud option was that local options either are bad or have too high ressource usage (important as /e/os supports a lot of underpowered devices). Overall a stupid move, but they adjusted the feature to let users make an informed choice

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/.

Lineageos might have quicker updates, though it is even more connected to google, except for not including microg. However a lot of people will need google play services so they will have to install it anyway

Personally I am using /e/os, but I think GrapheneOS is technically superior. I would first research whether the apps you need (EG banking) work on either one and then decide