[bramhaag]

> open-source means auditable privacy

This is what that auditing actually reveals:

* /e/OS sends user speech data to OpenAI without consent [1], and thought this was ok until they got caught [2].

* /e/OS massively delays security patches, and calls this a "standard industry practice" [3]. Meanwhile, GrapheneOS' opt-in security preview releases provide early access to security updates prior to official disclosure [4]. Also see [0] (Security update speed) and [7] (WebView being 40 security updates behind).

* microG downloads and executes proprietary Google binaries in a privileged environment [5] [6]. You can obviously not audit these, nor should this count as "degoogled".

* microG still phones home to Google by default (android.clients.google.com for device registration check-in, mtalk.google.com for FCM push, firebaseinstallations.googleapis.com for SIM activations) [7].

[0] has a comparison of popular privacy and security-focused Android-based OS, which paints the whole picture. Privacy-friendly does not necessarily mean secure, but in this case "privacy-friendly" is quite a stretch already.

[0] https://eylenburg.github.io/android_comparison.htm

[1] https://grapheneos.social/@GrapheneOS/114880528716479708

[2] https://community.e.foundation/t/clarification-about-voice-t...

[3] https://community.e.foundation/t/e-os-and-security-updates/7...

[4] https://discuss.grapheneos.org/d/27068-grapheneos-security-p...

[5] https://github.com/microg/GmsCore/blob/e19a9985204ec8329c1d9...

[6] https://github.com/microg/GmsCore/blob/e19a9985204ec8329c1d9...

[7] https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...

[microtonal]

And they give privileged access to a bunch of Google apps if you need them for e.g. Android Auto:

https://gitlab.e.foundation/e/os/GmsCore/-/blob/a9e102567518...

[mixmastamyk]

Your speech data assertion looks to be inaccurate, the user does have to opt in. Nor does the response sound like a mea culpa. I wouldn't use it, but seems reasonable for people who might want to.

[bramhaag]

Yes, sent*, not sends. Before they got called out, it was opt-out. No consent dialog, warning, or any other sort of confirmation before sending audio to OpenAI. The keyboard is auto-enabled.

Almost half a year after the controversy started, they added a consent dialog (https://gitlab.e.foundation/e/os/murena-voice-to-text/-/comm...). A few months later, they actually made the consent dialog function as intended (https://gitlab.e.foundation/e/os/murena-voice-to-text/-/comm...). Mistakes happen, but initially Murena:

1. sent voice messages to OpenAI

2. did not anonymise said voice messages, only their origin

3. did not ask the user for consent

4. ignored the user's consent after they started asking for it

That is not a good look for a privacy-focused OS. There is now a working consent dialog before using this feature, and audio is actually anonymised (random pitch shifting + filtering + noise), but it took them nearly 8 months to address all of this after getting called out.