PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2025-02-20 18:31:35 -05:00
Code

Reword sentence and embed link to Aurora token issue

Browse Source 
Signed-off-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
friendly-rabbit-35 2024-05-20 17:05:17 +00:00 committed by Friendly Rabbit
parent eeffedf8ab
commit 62cc5527cc
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/posts/android/F-Droid Security Issues.md
View File

@ -163,7 +163,7 @@ The Play Store for instance conveys the permissions in a far less misleading way
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 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?
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 that overshadow the rest.
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.
@ -207,7 +207,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 fairly recently. The last issue does not matter much since tokens were designed to be shared between users, which is already concerning. 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/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.
### Looking to the future