Hans-Christoph Steiner @eighthave@librem.one
Joined Aug 2019
Three years ago, #FDroid had a similar kind of attempt as the #xz #backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection #vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now
The #DigitalMarketsAct and other #competition actions against #gatekeeper app stores are based on the idea that an app store companies should not "self-preference" their own apps or services. This makes sense to a certain degree, especially when thinking about business. Ethical reasons must also be considered. #FDroid preferences apps based on #FreeSoftware and Anti-Features, which we as a community define. We should always be allowed to preference apps that follow standards of #UserFreedom.
I wish the #AndroidSDK team would follow repository best practices and stop silently reissuing binary releases under the same name/version. #MavenCentral does not allow this, for example. The #FDroid transparency log shows the newest violation: two version of sources-34_r01.zip with the file name, version code, and metadata.
git fsck makes it much harder to attack a git repo, but it seems that the normal git workflow does not enable it by default. In #FDroid it is enabled for all fetches in our config:
https://f-droid.org/docs/FAQ_-_App_Developers/#how-can-i-handle-fsck-error-in-packed-object-for-my-app
But I still can't find a clear answer about what checks #Git does by default. Anyone know?
I got the opportunity to go to #FOSDEM and of course I had my #FDroid "hat" on. I wrote up some quick impressions of my trip, including what I learned about the #EU's #DigitalMarketsAct #CyberResilienceAct and #ProductLiabilityDirective
There really are a lot of important projects represented there:
https://f-droid.org/2024/02/06/at-fosdem.html
Based on @maarten 's post https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/ I think the only people listed in my example that would be at all regulated by the #CRA would be the last one: "contracted contributors". It sounds like they might be considered "open source software stewards" with obligations under Article 17a depending on whether the #EU considers F-Droid as "intended for commercial activities"
https://www.cyberresilienceact.eu/the-cyber-resilience-act/
My guess is #Nextcloud/#Ubuntu would be considered commercial while #FDroid/#Debian would not
@roptat thanks for your nice visualization of #l18n in apps in #FDroid
https://i18n.lepiller.eu/i18n.html it is interesting to see which languages are the most active. If you're interested in more data sources, there are a lot of public data sources:
https://f-droid.org/docs/All_our_APIs/
For example, you might enjoy looking at the most popular search queries with the included language and country data:
https://fdroid.gitlab.io/metrics/search.f-droid.org/2024-01-29.json
After #FOSDEM my current understanding of how #EU #CRA and #PLD affects #FDroid and anyone who contributes to it:
* F-Droid org makes the "product" so it would be liable
* F-Droid is currently entirely non-commercial, handles no money
* Volunteer contributors are very clearly exempt from all this
* Donation funded contributions are also exempt
* Contracted contributors are helping build the regulated product, so the legal entities of the contractors would not be liable for F-Droid's "product"
So I messing around a bit more with stats data from the f-droid.org mirror hosted by @FAU in Germany:
* About 25% of the bandwidth of the mirror is for #FDroid
* Countries by percentage total bandwidth usage since /fdroid/ was added in 2019:
47.83% Germany
9.04% United States
5.13% China
3.68% Italy
2.69% France
2.55% United Kingdom
2.07% Russia
1.93% Switzerland
1.87% Estonia
1.82% Poland
1.70% Austria
1.40% Netherlands
1.38% Czechia
1.28% Canada
1/
#FDroid is consistently growing in its bandwidth usage over the years, as shown by this stats graph from the #UniFAU mirror. Interesting to see the short downward section when we added new official mirrors in April and November.
Thanks @FAU for the mirror, the bandwidth, and the stats! https://ftp.fau.de/cgi-bin/show-ftp-stats.cgi
@jcaleitao #FDroid has been trying to use your #IPFS gateway, but it does not seem to be working. https://ipfs.joaoleitao.org/ipfs/bafybeifx7yeb55armcsxwwitkymga5xf53dxiarykms3ygqic223w5sk3m returns "502 Bad Gateway" but that CID works on other gateways. Are you still maintaining your gateway? Are there restrictions on what it will host? f-droid.org is all free open source software apps, so should be uncontroversial.
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.
Joined Aug 2019
