There are mentions of discoveries and removals of proprietary bits in software recently. At F-Droid, do you consider these distributed, previously undiscovered, proprietary bits to be “malware”? I do. Either way, will there be any “formal” news about this?
While I understand your frustration (I feel it too), I think it’s important to recognize that most of the time these things happen by accident. Android has always been a “mostly open” platform, with little proprietary bits and pieces everywhere. Together with Google’s unclear documentation, it is very easy to think something is libre because it is part of Android, only to later find out it isn’t. With calling it “malware”, well, I wouldn’t call the apps on F-Droid themselves malware as in the vast majority of cases the developers take our concerns seriously and it gets fixed in the next release, so everyone who is on a version with proprietary code ends up getting upgraded to a fully libre version not too long after. Developer willingness to fix these issues so quickly when pointed out show they don’t have any malicious intent. However, one could argue Google purposefully makes things unclear to make Android seem a more open platform than it really is.
You may have noticed that we’ve had “a lot of incidents” lately. While this seems frustrating, it’s actually a good thing, because it means we’re finding more things previously undiscovered. Specifically, after certain improvements to the scanner this ticket was created: Run `scan-binary` on a full repo/archive mirror (#1004) · Issues · F-Droid / fdroidserver · GitLab.
Given how fast Android moves and to balance between ensuring all apps on F-Droid are libre and that app updates get to users quickly, we work with a mix between an allowlist and denylist. Specifically, we allowlist some Maven repos that have general good practices, while denying specific packages that we feel aren’t acceptable for apps on F-Droid. While this isn’t perfect, we simply don’t have the resources to check everything constantly. And even if we did, it would take a lot of time and delay updates which many users won’t find acceptable (we already get many complaints F-Droid is “slow to release app updates”).
I personally don’t really think any formal announcement of this is necessary. Stuff sometimes happens, we work with developers to get it resolved, and then users are upgraded to new clean releases. And in between it all we keep improving the denylists and scanner to improve our detection rate.
10 Likes
I personally don’t really think any formal announcement of this is necessary. Stuff sometimes happens,
There are a couple ways to spin this: (a) big improvement, or (b) big failure to achieve F-Droid goals, for who knows how long, for who knows how many apps. I’ll echo @eighthave 's suggestion at that same issue, and add a suggestion of including some numbers like a score card. Maybe it could be an ongoing scoresheet or metric.
It would be great to have a blog post on this topic, even just a single short paragraph. Run `scan-binary` on a full repo/archive mirror (#1004) · Issues · F-Droid / fdroidserver · GitLab
Reading between the lines of Sylvia’s comment you might have guessed this had happened before. And as Sylvia pointed out, we improve our scanners (yes, plural – we use multiple of them and still cannot be sure we catch everything), with their “signature lists” being constantly improved. So from time to time, we “go back” and scan what probably was not covered by the newly added definitions – and, for the reasons pointed out, usually find “something” each time. One and a half year ago, I was running a comparable action, which I split across multiple tickets; you can find one of them here.
So what do I want to say by this? Just that we do such checks not just once, but more or less regularly. To make sure you (the users) get “clean apps”. To make sure the developers are being aware of what “silently sneaked into their apps” and they can take care for it.
Nothing is perfect, and nothing will ever be. But that won’t keep us from giving our best. So this won’t be the last time I’m afraid…
2 Likes
It is understandable that there are slips, it’d be nice to have a central list on the website to find apps that were disabled as such.
Nothing crazy detailed, even just app, version, and date disabled would be great.
Because as it is now they just go poof! And users will still have them installed.
Other users will question where they went.
GitLab doesn’t even allow basic searches when not logged in either.
4 Likes
Yes… this has been a bit of a problem with RepeaterSTART for Amateur radio users, there was some Google library hiding in dependency of a FREE dependency…
Even after I created a new build version with these excluded, days ago, it is still not republished 
There is metadata in the repo so you could search for "disable: " within the directory to see exactly how many are disabled? metadata/com.hearham.repeaterstart.yml · master · F-Droid / Data · GitLab
1 Like
It would be great if it worked over Orbot too. 
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.