Update status of unattended updates and test slightly different update placement

Signed-off-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com>

content/posts/android/F-Droid Security Issues.md

@@ -105,6 +105,7 @@ There is indeed a serious security issue with the OS first-party source feature
 On that note, it is also worth noting that the repository metadata format for F-Droid isn't properly signed as it lacks whole-file signing and key rotation. [Their index v1](https://f-droid.org/2021/02/05/apis-for-all-the-things.html#the-repo-index) format [uses JAR signing](https://gitlab.com/fdroid/fdroidserver/-/blob/d70e5c2cd92eb1924caf51a1f88202749956038f/fdroidserver/signindex.py#L40) with `jarsigner`, which has serious security flaws. F-Droid added their [index v2](https://f-droid.org/docs/All_our_APIs/#the-repo-index) format with [support for `apksigner`](https://gitlab.com/fdroid/fdroidserver/-/commit/3182b77d180b2313f4fdb101af96c035380abfd7#e915676f3ed7e51adef7ee3d1eaa0ef7be386a84) in May 2022, but this just seems to be an over-engineered and flawed approach since better suited tools such as `signify` could be used to sign the metadata JSON.
 
 As a matter of fact, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the aforementioned third-party client [Neo-Store](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29.
+*Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates, but the issues with the privileged extension when installing apps through F-Droid still remain.*
 
 F-Droid's official client also lacks **TLS certificate pinning**. Certificate pinning is a way for apps to increase the security of their connection to services [by providing a set of public key hashes](https://developer.android.com/training/articles/security-config#CertificatePinning) of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (*man-in-the-middle* attack) could be possible and lead to various security issues, considering you're trusting an app to deliver you other apps.
 
@@ -161,7 +162,8 @@ In modern Android, the background restriction toggle is what really provides the
 
 Another example to illustrate the shortcomings of this approach would be the `QUERY_ALL_PACKAGES` low-level permission, which is referred to in F-Droid as the *query all packages* permission that "allows an app to see all installed packages". While this description is somewhat correct, it can also be misleading: apps do not need `QUERY_ALL_PACKAGES` to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default [since Android 11](https://developer.android.com/training/package-visibility)). If an app needs more visibility, it will declare a `<queries>` element in its manifest file. In other words, `QUERY_ALL_PACKAGES` is only one way to achieve visibility. Again, this goes to show how low-level manifest permissions are not intended to be interpreted as high-level permissions that the user should fully comprehend.
 
-The Play Store for instance conveys the permissions in a far less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by tapping "About this app" then "App permissions - See more" at the bottom of the page. The Play Store will inform the user that the app may request access to the following permissions; this kind of wording is more important than it seems. *Update: since July 2022, the Play Store doesn't offer a way to display low-level permissions anymore.*
+The Play Store for instance conveys the permissions in a far less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by tapping "About this app" then "App permissions - See more" at the bottom of the page. The Play Store will inform the user that the app may request access to the following permissions; this kind of wording is more important than it seems.
+*Update: since July 2022, the Play Store doesn't offer a way to display low-level permissions anymore.*
 
 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...