In my work with #FDroid I've discussed our work with gov regulators for South Africa, UK, EU and Japan as well as competition litigators from multiple US States and the EU. From this, I'm starting to see a picture of #Apple's and #Google's semi-related strategies of making "sideloading" (installing apps outside of their #gatekeeper control) look bad as a way to keep their monopolies in the face of #DMA and other regulatory actions. I'm still looking for data about the actual real world risks 1/
When organizations that use #Debian maintain the packages they use in Debian, the whole ecosystem gains. The more organizations that do that, the more efficient the whole ecosystem becomes for all users. Here's a recent example from #FDroid:
https://f-droid.org/2023/10/10/f-droid-maintains-in-debian.html
I'm a Debian Developer, I'm happy to help get organizations working in this way. Reach out if you're interested!
Statements like this make me question if #BleepingComputer is actually a useful info source:
"Since APKs downloaded from outside Google Play cannot be vetted, the best way to protect against these threats is to avoid installing Android apps from third-party sites in the first place." https://www.bleepingcomputer.com/news/security/thousands-of-android-apks-use-compression-trick-to-thwart-analysis/
#FDroid not only vets the binaries it ships, it also vets the source code. #GooglePlay is not the safest source of apps on #Android.
On the public #Weblate, mystery accounts are creating Old English (ang) and Middle English (enm) in the #FDroid projects. They don't respond to my messages, or do any translation work. This makes me suspect foul play. Anyone have any ideas?
For example:
* https://hosted.weblate.org/projects/f-droid/-/ang/
* https://hosted.weblate.org/projects/f-droid/-/enm/
I still don't get why #Apple #AppStore or #GooglePlay do not allow devs to give source when uploading apps for review. It makes review tasks much easier and more reliable, as we've seen with #FDroid's review. Would it scare the #proprietary app devs too much? Are they more interested in cheap "window dressing" reviews than actually catching things? It is hard not to see bias since both are #gatekeepers getting lots of money from apps they are policing.
For example
https://arstechnica.com/gadgets/2023/07/apple-tries-to-close-privacy-loopholes-with-new-app-submission-policy/ 1/
Looks like the latest release of #FDroid, v1.17.0, does not get flagged by #Google, at least in the #Android 14 emulator. I heard some reports that v1.16.4 also isn't flagged. I don't really know why its flagging F-Droid then. v1.16.4 has an unchanged #targetSdkVersion, but v1.17.0 has it bumped to 28. I have found no way to get info on why they are flagging the app, just this silly "unsafe" warning screen. Is F-Droid being flagged by Google Play Protect on your devices? Please let me know.
We can set up #internet communities with hard requirements to respect the community. This is why #FDroid is legally structured to put #FreeSoftware first and foremost, via legal structures set up by Commons Conservancy.
I will go one step further and say that calling #FDroid an "unsafe app" by this standard is dishonest. It seems that some at #Google also agreed, since the older version of that screen was honest: "Blocked by Play Protect" instead of "Unsafe app blocked". Looks like the #GooglePlay team is still focused on protecting their #monopoly, this time using scare tactics. 2/2
This screen that #Google shows on #Android when installing #FDroid really bugs me. It is purely based on the integer value targetSdkVersion, without considering our security model, public audits results, track record over 10+ years, exclusive use of memory safe languages, or even what our code actually does. It is as if #FDroid marked anything that comes from Google as containing ads and trackers. 1/2
So the #Bitwarden ad on this #FLOSSWeekly episode says: "Bitwarden doesn't track your data, only crash reporting, and even that is removed in the F-Droid installation." at around 16:30 https://twit.tv/shows/floss-weekly/episodes/720
Maybe not a big deal, but it seems like a new level for #FDroid: people paying money to promote based on F-Droid's principals, in this case, opt-out data collection is tracking.
Do you sometimes just want one tool from the #AndroidSDK in a container or VM, and don't want to deal with the whole pain of setting up #Java and everything? Try the #FDroid sdkmanager instead of the official one. For example, `apt-get install sdkmanager` then `sdkmanager platform-tools`. Plus this verifies all packages using `apt-get` style GPG-signed index with SHA256 values. Useful in #research on #Android #malware #tracking etc. In pypi, Debian, Ubuntu, and https://gitlab.com/fdroid/sdkmanager/
Just tagged v2.2.1 of #FDroid fdroidserver tools package, and uploaded it to pypi.org, #Debian, and our #Ubuntu PPA. This version has passed autopkgtest in Debian/bookworm, so it looks like it should make it into bookworm without further work https://tracker.debian.org/pkg/fdroidserver
#Apple's representative gave a classic, well polished FUD PR piece framed as lots of questions. Of course, I fully agree that human review of apps is key to trustworthy app stores, that's why #FDroid goes the whole way and requires apps provide the whole source code to be review, not just the binaries. And F-Droid does done this since 2010 even though #FDroid is not a #gatekeeper. Being the only app store on the platform locks out app stores that do better review than #apple. #DMAWorkshop
Flying to Brussels, I was offered some digital boarding pass format which I was not familiar with: #Passbook pkpass. Living #GoogleFree, I assumed it was some proprietary thing. But I searched #FDroid and found @ligi 's app:
https://f-droid.org/packages/org.ligi.passandroid/
It worked perfectly! #FreeSoftware #FTW
@webmink I greatly enjoyed your live tooting of the #DMAWorkshop. I'm up next: this Monday is the next one, this time about the app store regulations. I'll be there representing #FDroid @fdroidorg. Any advice for pushing #FreeSoftware in that context?
#fdroid client is configured with two #Maven repos: Maven Central and the Google one. Yet running `./gradlew buildEnvironment --scan` downloads `org.gradle:gradle-enterprise-gradle-plugin:3.10.2`, which is not available on those two repositories. It seems that #Gradle is adding repositories automatically, that seems sketchy to me. I confirmed this by running `gradle --write-verification-metadata sha256 buildEnvironment --scan`
Just uploaded to #Debian the key #Android inspection tools #apktool 2.7.0 and the latest #smali from git, ahead of 2.5.2. All sorts of tools like #droidlysis #fdroid #kalilinux and more rely on these for inspecting Android APK files.
This level of vigilance is hard, so we have added another layer of defense in the upcoming #FDroid client v1.16 release, currently in beta. We've moved the database to be based on #Room and its built-in #security measures, then had that new code audited https://f-droid.org/2022/12/22/third-audit-results.html 2/2
#Debian and #FDroid require signature verification, and #FDroid is built on top of #Android's APK signing. This improves things a lot but does not mean they are immune. Debian and F-Droid repos can still override packages lower priority repos. It could make sense to have a "no overrides allowed" setting, but that would restrict useful features. Maybe F-Droid could implement "no new signing keys when overriding" rule by default, I wonder how much that would break what people are doing now? 2/2
@Gargron is providing a shining example of the new breed of "startup" culture that is arising. We want impact in the public interest, and just to make a living doing it. Getting rich is besides the point, and it is certainly not a reason to compromise the goals of the project. I believe #FDroid is another example of this.