Kiwix app hasn’t been updated since 2018.
It would be useful to add out-of-date flag to apps for security and transparency reasons. AUR and other package managers already have this feature.
2 Likes
How long should “date” be?
18 months.
Yes, this would be quite useful. It can be a filter/flag while searching for apps.
1 Like
It could make sense to discriminate not simply on the age of the last update but rather adopt a more articulated approach.
There are old apps that can still be of use on recent android versions, others may go problematic after a much shorter time.
Or, say an app relies on a feature that’s been removed from the latest Android version but works on previous ones and the dev keeps supporting it for that audience.
Much depends on what google does to android itself, e.g. the introduction of scoped storage could be a decent example.
And F-Droid, as far as I understand, does endorse explicitly the idea of providing old devices with apps they can use.
So whether an app is irredeemably outdated can be a “in eye of the beholder” sort of thing, to an extent.
Perhaps it would be more meaningful to list what android versions are supported by an app, either explicitly or implicitly.
This information could be gatherrd from users themselves, as suggested, to maintain up-to-date information on projects that have gone silent, too.
1 Like
Things change often in Android, and vulnerabilities can easily appear in older versions of dependencies (see the discussion on known security vulnerability flags a few months back). So I think it’s fair to say that any app that isn’t getting ongoing maintenance presents a risk, even if it’s a simple app that still functions without it. Some actively maintained apps only release new versions every 6 months, or even every year, but I’d say flagging an app as “unmaintained” after one year with no new release is a good rule of thumb.
As with the anti-feature and known vulnerability flags, it’s just a way of letting people using F-Droid know of a possible risk. What we do with that is up to us.
Things change but I was extremely happy when I was recently directed to a “totally outdated” SIM contacts editing App. Even though very old it helped me avoid security pittfalls of a presumably state of the art contact App.
Very much so. Those of us who have older hardware actually PREFER these older apps since, unlike newer stuff, they can actually RUN on the devices we have.
Yes, I know I can toggle a setting for whether to show “incompatible” apps, which in theory should allow eliminating the “too new” (for an older device) type of apps. But I generally end up setting it to show everything regardless, simply because quite often the database gets it wrong and filters out apps which actually DO work. I verify this by trial & error, using a browser to download and install them manually. And I also know that if expanding the section about versions, then the detail for each version, I can see what Android version it is tagged for. But it would be much easier if this info was presented in the upper portion of the description rather than forcing me to hunt for it. I think some older versions of the fdroid app used to show this better, but recent versions no longer do.
I’d rather see these types of issues resolved than have yet more counterproductive AF tagspam.
And of course there is the question of these flags being a pretext to flat-out deleting older apps from the repo entirely, much as the play store does, which would be a VERY BAD thing.
We have the “known vulnerability” tag for that, there is no need to create yet another tag that is ultimately redundant with this already existing one.
This very much depends on the type of app and what it is doing. For some things, “if it ain’t broke, don’t fix it” makes a lot more sense.
There’s just no way everybody is going to agree on one specific time period for what is “too old”.
Perhaps a better idea would be to put 2 new settings into the client. One would be a checkbox for whether to filter out apps completely vs merely flag them. The other would be a user adjustable amount of time (in days? or should it be months?) since the last update, to generate such a flag/filter for those who want to set it.
A value of 0 could say to ignore the dates, similar to the current situation, this could be the initial default value.
Even better, a negative value could say, exclude/flag anything newer than X days (months?) ago, for those of us who prefer older apps while those who want the latest can keep their positive values and don’t need to be disturbed by these things.
This idea could even be extended to put a limit on the number of older/newer versions that are shown if the versions section is expanded, based on whether their dates match, rather than only flagging/excluding the entire app based on the date of the latest release (for those of us who use the “archive” repos).
Yup. Sometimes newer is NOT always better.
Absolutely agree. I often run older devices and I appreciate having the older apps available.
I actually think it would be really useful to have separate F-Droid repos for brackets of older Android versions, containing only the apps known to work on those versions. If there’s a way of detecting Android version during install, the appropriate repo could be made default during install. Or version number could be asked for during the onboarding process, after installing the F-Droid app, which could then set the default repo. In both cases, the onboarding could also tell the person about this, and how to turn on the general repo if they’re willing to risk apps not working on their version.
I’m aware this could create a lot of extra work for already over-stretched F-Droid volunteers. But some of that work could potentially be automated, and people like @freecycler and myself could volunteer to test apps on our older devices and give feedback on which ones work, with which Android versions.
Coming back to the issue of ongoing maintenance, some of the issues I’ve had with running apps on older versions involve things like TLS certs expiring. We’ve had some success with getting app maintainers to hack around this (eg Delta Chat and AntennaPod), which has kept these apps running on older versions. Obviously this isn’t possible with an unmaintained app.
Another issue I’ve struck is that many apps in F-Droid provide no obvious way to export user data. So starting to use them if they are unmaintained could result in headaches down the road if they are flagged with a security vulnerability. So while the security vulnerability warnings in F-Droid make it much less important to flag apps as (potentially) unmaintained, I still think it would be a useful flag.
Sounds good to me. Just to be clear, I’m proposing flagging apps as (potentially) unmaintained, not removing them from F-Droid after an arbitrary amount of time with no releases. As I said;
But if I had the option to filter out apps that haven’t had a release in over a year from my searches in the F-Droid app, I would probably use that.
we already have the Archive repo, and the Client(s) should be able to install only the compatible versions. (bugs aside heh)
True, but what I’m proposing is something more granular. As an example, imagine there was a repo for each major Android release, from 1.0 to 14.0 etc. Now in practice, there wouldn’t need to be that many, because a) there are almost certainly no pre-3.0 devices still in use, and b) the OS changes that break apps tend to only come every few releases. So for example, a repo for all pre-5.0 releases would probably be fine.
Again, I understand that setting up and maintaining such repos would be a lot of extra work, and I’m not suggesting that core F-Droid maintainers take it on. But if there are a bunch of us motivated to help people keep older devices in use, it could be a community project.
Another potential benefit of such a system, if we could bootstrap it, is that it might encourage app devs to keep maintaining old apps for longer. Or return to maintaining currently abandoned ones. Because it surfaces the benefits of doing so for people using older devices.
Well, there’s “compatible” and compatible. In practice, I’ve often installed apps from F-Droid on older devices and run into headaches (many of which I’ve reported in this forum), such as the outdated TLS versions problem. I’m sure @freecycler and others have struck the same sorts of issues.
you must have known I couldn’t resist replying to this…
While probably relatively few compared to newer models most people have, there is definitely at least one. My favorite “daily driver” runs FroYo (Android 2.2).
Keeping an extra repo would involve the initial index work of splitting it out, plus ongoing work if apps later need to migrate into another bucket (would you later want another repo for, say, Marshmallow through Oreo?). I’m not even clear there would be any benefit, assuming the bugs around accurately determining app/device compatibility could be fixed.
But for the filtering idea, there is only the one-time work of adding the new function to the client. All of the needed data is already present in the index so there is no additional work needed there.
The certs themselves can be updated easily enough, especially if you have root. What is more problematic is the older versions of libssl.so that do not handle newer encryption algorithms. Even with root I have not yet managed to update this.
Often (though not always for all apps), ADB can be your friend, even without root.
Well, for older androids like my favorite, that can mean using MUCH older versions of the client… and the older versions for a device running FroYo are missing so many bugfixes (can a version that old even read the index anymore?) that it is easier to just skip the client and use a web browser. Even the latest version frequently gets it wrong for less-old devices running, say, Lollipop and cannot tell what is or isn’t compatible. So yeah, bugs aside etc.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.