2025-02-20 18:31:35 -05:00 · 2024-10-28 16:28:49 -07:00 · 2024-10-28 16:28:49 -07:00 · 18d31a3b85
commit 18d31a3b85
parent 06bfed279f
1 changed files with 3 additions and 3 deletions
--- a/content/posts/android/F-Droid
+++ b/content/posts/android/F-Droid
@ -181,7 +181,7 @@ The Play Store, for instance, conveys the permissions in a far less misleading w

 Moreover, [the Play Store restricts the use of highly invasive permissions](https://support.google.com/googleplay/android-developer/answer/9888170) such as `MANAGE_EXTERNAL_STORAGE`, which allows apps to opt out of scoped storage if they can't work with [more privacy friendly approaches](https://developer.android.com/guide/topics/providers/document-provider) (like a file explorer). Apps that can't justify their use of this permission (which again has to be granted dynamically) may be removed from the Play Store. This is where an app repository can actually shine, particularly with a review process to protect end users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place...

-## Conclusion: what should you do?
+## Conclusion: What should you do?
 So far, you have been presented with referenced facts that are easily verifiable. In the next part, I'll allow myself to express my own thoughts and opinions. You're free to disagree with them, but don't let any disagreements overshadow the facts.

 While some improvements could easily be made, I don't think F-Droid is in an ideal situation to solve all of these issues because some of them are **inherent flaws** in their architecture. I'd also argue that their core philosophy is not aligned with some security principles expressed in this article. In any case, I can only wish for them to improve since they are one of the most popular alternatives to commercial app repositories, and are therefore trusted by a large userbase.
@ -226,7 +226,7 @@ Some people tend to exaggerate the importance of Google in their threat model, a

 **The Play Store evidently has some privacy issues**, given that it's a proprietary service which requires a Google account (this cannot be circumvented), and Google services have a history of nagging users to enable privacy-invasive features. Again, some of these privacy issues can be mitigated by setting up the [Play services compatibility layer from GrapheneOS](https://grapheneos.org/usage#sandboxed-google-play), which runs Play services and Play Store in the regular app sandbox (the `untrusted_app` domain). [ProtonAOSP also shares that feature](https://protonaosp.org/features#privacy-and-security). This solution could very well be ported to other Android-based operating systems. If you want to go further, consider using a properly configured account with the least amount of personally indentifiable information possible (note that the phone number requirement appears to be region-dependent).

-If you don't have Play services installed, you can use a third-party Play Store client called **[Aurora Store](https://auroraoss.com/)**. Aurora Store has its own issues, some of which overlap with F-Droid's. Aurora Store somehow still requires [the legacy storage permission](https://gitlab.com/AuroraOSS/AuroraStore/-/blob/master/app/src/main/AndroidManifest.xml?ref_type=heads#L34-36), has yet to [implement certificate pinning](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/697), has been known to sometimes retrieve wrong versions of apps, and [distributed account tokens](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/722) over [cleartext HTTP](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/734) until late 2021. The last issue does not matter much since tokens were designed to be shared between users, which is already [concerning](https://gitlab.com/AuroraOSS/AuroraStore/-/wikis/Anonymous%20Logins#why-do-aurora-store-always-say-session-expired). I recommend against using the shared "anonymous" accounts feature; you should make your own throwaway account with minimal information.
+If you don't have Play services installed, you can use a third-party Play Store client called **[Aurora Store](https://auroraoss.com/)**. Aurora Store has its own issues, some of which overlap with F-Droid's. Aurora Store somehow still requires [the legacy storage permission](https://gitlab.com/AuroraOSS/AuroraStore/-/blob/98322b33589b68df003a3b327e51a2b716c5ebf7/app/src/main/AndroidManifest.xml#L34-36), has yet to [implement certificate pinning](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/697), has been known to sometimes retrieve wrong versions of apps, and [distributed account tokens](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/722) over [cleartext HTTP](https://gitlab.com/AuroraOSS/AuroraStore/-/issues/734) until late 2021. The last issue does not matter much since tokens were designed to be shared between users, which is already [concerning](https://gitlab.com/AuroraOSS/AuroraStore/-/wikis/Anonymous%20Logins#why-do-aurora-store-always-say-session-expired). I recommend against using the shared "anonymous" accounts feature; you should make your own throwaway account with minimal information.

 ### Looking to the future

@ -242,4 +242,4 @@ This article aims to be **purely technical**. It is not an attack on F-Droid or

 In spite of this, the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who seem to take a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals go as far as engaging in harassment campaigns against projects and security researchers who do not share their views. Hopefully, they realize that such unethical behavior undermines their own project and reputation. Creating a rift between developers and security researchers is not in anyone's best interest.

-Some individuals have also falsely associated this article with GrapheneOS. _This article is an entirely independent work and unrelated to the GrapheneOS project. It was not written by a GrapheneOS developer and does not claim to represent the GrapheneOS project in any capacity._ Either way, dismissing the article on the basis of association instead of addressing the actual technical content is silly and not helpful to anyone.
+Some individuals have also falsely associated this article with GrapheneOS. _This article is an entirely independent work and unrelated to the GrapheneOS project. It was not written by a GrapheneOS developer and does not claim to represent the GrapheneOS project in any capacity._ Either way, dismissing the article on the basis of association instead of addressing the actual technical content is silly and not helpful to anyone.