I am against having an expiry date for AppManager and this is my ideas for a better solution (maybe)

[0xRustlang]

Please check before submitting an issue

• I am using the latest version of App Manager
• I have searched the issues and haven't found anything relevant
• I have read the docs

Describe a description of the new feature

I don't like having an expiry date for AppManager because in my threat model it doesn't provide a better security for me (and probably many others)

Describe the solution you'd like

I am prepared a comment about this matter that it isn't completely in a format that I fill this forms properly but I try my hardest.

Probably it is better that I write is fully in alternative form below.

Describe alternatives you've considered

I think having an expiry date and specially forcing the user to remove the app isn't a great approach.

Although I really pleased with the fact that you this much care about security of the users and am grateful for it.

I like to say some use cases that the user probably won't get in danger of using an old version of AppManager.

Because of not so much good English and because I want to my comment be as clear as possible, I will use numbers.

1. Maybe a user just use AppManager in non-root mode that from what I think it doesn't possess real security risk.

2. You, yourself already use or had used F-droid classic that hadn't updated for years so using an old version of an app as long as the user be careful or it be compatible with the threat model of the user won't possess the user to real danger.

3. There are many other security issues that can expose user to risk than just AppManager like old android system webview and many more.

4. (And maybe my main point):

Probably many users because of some reasons may already use old versions of Android and old version of apps so just not being able to use AppManager in that case won't have any more security enhancement to user. Specially if they use it in non-root mode.

Worse, some users may use molded apps (that is unfortunately common) and that fact is far more dangerous than using an old version of AppManager.

7. Isn't it better that you make the AppManager to warn the user everytime after that expiry date ended and not force them to remove it?

Or in addition to that you can also force user to just they can use non-root mode and can't use other modes.

What do you think about my comment and the last alternative solution?

BTW, Thank you for this great app. It is a real life saver.

Best wishes.

Additional context

Also there is a possibility that someone fork AppManager and remove those limitations and many users go to that fork.

The issue here can be two, one is bad and other is a disaster.

1. That person may just remove expiry limit.

2. That person may put suspicious code in the app and because AppManager gets powerful permissions in adb and root mode, that will be a disaster.

Best wishes.

[MuntashirAkon]

I don't like having an expiry date for AppManager because in my threat model it doesn't provide a better security for me

It's okay to dislike certain decisions and asking the maintainer to reevaluate them. But saying that having an expiry date doesn't provide a better security for me is just wrong in this case. However, this could simply be a language gap.

I am prepared a comment about this matter that it isn't completely in a format that I fill this forms properly but I try my hardest.

Yes, it could've been a discussion. But it's still okay since an issue gets more attention than a discussion.

I shall respond to all the points you've mentioned here in case the issue is raised again in the future.

1. Maybe a user just use AppManager in non-root mode that from what I think it doesn't possess real security risk.

There's always a risk, even in no-root mode. The goal of App Manager is to identify itself as the most complete package manager which is not nearly as complete. If you browse the issues here in GitHub, you will get a clearer idea on where the development of App Manager is going. But to reach that goal, App Manager has to utilise a lot of permissions. To those unaware of the concept of permissions in Android, utilisation of permissions does not appear to be a bigger deal. But those who are aware know that permissions are the loopholes in the application sandboxing like the faults in the sun. It should not come as a surprise if you read my post in Telegram which explains how it is possible for an ordinary app to bypass sandboxing by utilising a certain permission, namely android.permission.INTERNET. To understand why this is relevant to App Manager, you have to be familiar with its development. App Manager is a massive project developed by one individual, namely myself. This solo development possesses significant risks since the source code is not reviewed by anyone but me (it's like writing, you don't see any spelling mistakes in your writing but show it to your friends, they will find many) and is currently in a state that makes it difficult to review by individuals (and I cannot afford to get it reviewed by any organisation). As a result, despite my careful attention, some of the risks can never be discovered and can be exploited by malware as the malware developers prefer vessels over any other alternatives. App Manager, in this case, is particularly attractive due to its extensive use of permissions and the nature of users. You can already find some interesting known exploitation techniques by filtering the issues by the label security although most of the serious security issues are never disclosed till now as App Manager does not yet have a vulnerability management system. But using App Manager, even in no-root mode, a malware might be able to access the storage, the Internet, list of applications installed in the system, install random apps, system logs (which may or may not contain personally identifiable information), app usage, network usage, device fingerprints among others. These are the basic information that no users would want to find it in the hands of a hacker/state actor.

2. You, yourself already use or had used F-droid classic that hadn't updated for years so using an old version of an app as long as the user be careful or it be compatible with the threat model of the user won't possess the user to real danger.

I had to use F-Droid Classic because there were no alternatives, and F-Droid was the only source of apps in my device. The official F-Droid app, likewise, could be vulnerable to many attacks including RCE as the target SDK is still below 29. Instead of these apps, the alternatives such as Droid-ify or Neo Store should be used (until App Manager itself provides a much better alternative).

3. Probably many users because of some reasons may already use old versions of Android and old version of apps so just not being able to use AppManager in that case won't have any more security enhancement to user. Specially if they use it in non-root mode.

Using old version of App Manager in old operating system would be much worse as the potential vulnerabilities described earlier could enable a malware to use a more generic method to carry out targeted attacks. For example, App Manager versions prior to v2.6.0 had a RCE vulnerability that let third-party apps obtain and utilise root through App Manager. However, the real cause would be elaborated much later.

4. Worse, some users may use modded apps (that is unfortunately common) and that fact is far more dangerous than using an old version of AppManager.

The entire purpose creating of App Manager, as you might be aware, was to make people aware of the privacy and security of implications of the apps they use. This is why I felt the necessity to merge a few apps that I use daily for enhancing the privacy and security of my device. I've only decided to make the app public because I thought others might also be looking for such solutions. The purpose, despite receiving more attentions that I expected, has still remained the same. Apps can be modded for good and for bad. For example, a rogue app can be modded to remove certain permissions or components that is harmful to privacy and security, just as it could be modded to deliver malware alongside some pleasing features. Therefore, in App Manager, generic security issues are carefully marked in the App Info tab, could be scanned by Scanner, and could even be scanned by VirusTotal. So far, some successes have been seen in raising awareness regarding the harmfulness of modded apps as you may have seen yourself.

5. Isn't it better that you make the AppManager to warn the user everytime after that expiry date ended and not force them to remove it?

How this feature works is described in #889. In summary, the user shall see a warning for several weeks before the build would be disabled. But this, I believe, is not the right question. The right question would be the factors that might be preventing a user from updating the app. Why would a user still use v2.5.23 instead of v3.0.3? Do they prefer their personal data to be sold in a market place in the Darknet? I'm sure they don't. Several years ago, several private photos of Hollywood celebrities (mostly females) were leaked. Although almost all of them appeared partially or completely nude in some of their movies, they still didn't take this leak lightly, which suggested that their bold statement regarding their having nothing to hide is not something they themselves believe in. Philosophy is what makes App Manager different from most other apps. I would rather discontinue my project than let hackers use it for stealing information from its users.

Or in addition to that you can also force user to just they can use non-root mode and can't use other modes.

The way the limits are set, it's unlikely that a user would face any troubles as long as the development is active. If the development is inactive or somebody else takes it over, signatures would also change. One thing people should realise is that nothing lasts forever. Electronic devices aren't made to last nor is Android itself or any of its apps. Sooner or later, it will reach the expiry date and will no longer function. App Manager is no different. It is signed with a time limited certificate which will also expire at some point in the future. But even before, singing schemes such as v1, v2 and v3 themselves might be discontinued. Many other crucial apps also have a expiry date that you often do not see because they never told you so and you never really used the old version of the app that long without updating, or in case of an API client, the API itself might be changed, rendering the client useless.

Also there is a possibility that someone fork AppManager and remove those limitations and many users go to that fork.

It's quite easy to remove this limitation by either editing the app or forking it. In both cases, the signature would change, thereby, making it a “covered work” as per the license of the app. Multiple warnings have been issues in the past regarding modded version of App Manager. If a user prefers these over official App Manager just because they do not want to update it to the latest version, they might as well do it. An unmaintained app is a vulnerable app regardless of whether you use the original or the modded app.

[J4CKED]

I didn't know the app had a time limit. Does it work like Whatsapp? And after a certain amount of time it is impossible to use the app?
Of course, I am against it.

[MuntashirAkon]

Does it work like Whatsapp? And after a certain amount of time it is impossible to use the app?

Yes.

Of course, I am against it.

The question is not for/against anything. I am not a corporate entity deciding against the users, we should be clear on that. Rather I want the users to be safe from any potential harms that might be introduced by the app. However, as I've delicately put forward the reasoning behind the decision, the only sane way to divert me is to provide convincing justification as to why this should be a bad idea.

[J4CKED]

I will give a comparison like this. You buy a car that has 300HP, but for our safety, the government decides to limit it to 200HP.

[MuntashirAkon]

I will give a comparison like this. You buy a car that has 300HP, but for our safety, the government decides to limit it to 200HP.

Well, a car and its driver require a government-issued license/ID as well as insurance. The obtaining a driving license requires that you know how to drive safely knowing the traffic rules, abide by the rules and are aware of the penalties in case they are broken. A driver, as a result, has to go through sufficient training to ensure that they have mastered enough before appearing in the exams. Even then, you have to renew the license after a few years in most countries. There is no such thing for an electronic device, apps or their user that would ensure that the user is not only aware of but also ensure the safety of their device in a world where data theft is ever so transparent (that is, hidden) and a common incident. This is why privacy-respecting apps are gradually introducing expiry dates. Among the front-ends (back-ends always have had expiry dates), Signal added it a long time ago to ensure the safety of the messages, Bromite only displays a warning because it has no control over the updates, and many others are trying to figure out the best way to implement it. This is usually done without any announcement because the user, in general, has nothing to be afraid of as long as the development is active (if it is no longer maintained, the users should not use it anymore no matter how useful it is). But I think you haven't read my early replies and commented only on the title of the issue.

[J4CKED]

Anyone can drive a car without a license. This can be done on a private road without fear of a fine.
A private road is like a phone without internet access.
After all, I can use AppManager offline.

In the application it is enough to give a warning about the existing danger. People can read and think, if not then let them pay for their mistakes.
I don't need someone to lead me by the hand and force me to update.
I still use the old QuickPic photo app.

I think this is a topic for conversation over a beer, because I feel that nothing and no one will convince you.
Merry Christmas :)

[0xRustlang]

Thank you for explanation.

You're right.
Also I had forgotten every app has an expiry date for its signature. (Although it is probably longer than the usage of that phone or at least the phone will become useless for those operations in that time :)

I can understand your reasoning but let's say, you force users to remove the app from their device.

What will happen if someone else push an malicious fork of it and users go to it?

It won't be better than using latest version I think.

Also probably it can be worse if usere downgrade to latest version that doesn't have that limitations.

I have few old devices like @J4CKED that is use old version of apps in them (devices that doesn't have Internet access and such)

BTW, I tried to explain the use cases for users that have a disconnected phone like me.

But the decision is yours ;)
Thanks.

[MuntashirAkon]

@Rustlang4Future: What I do not understand, as I've already specified in the second comment if you've read it carefully, is why anybody should continue to use the old versions instead of the new ones.

Let me explain how support in App Manager works here. While this is quite common in a desktop environment, due to abstractions made by Google Play Store (and most people use Google Play Store), this is mostly unknown to the Android users unless they are familiar with the desktop environments.

We have several version lineups, as you can see in the docs, such as v2.5.x, v2.6.x, v3.0.x and (coming up) v3.1.x. We have discontinued support for v2.5.x this year because we have received only a single report in a year. This is what I posted in the Telegram channel regarding the decision:

Important.

App Manager v2.5.x and earlier versions did not received any security updates for more than a year and should not be used.

For root and ADB users, this is very crucial because today crackers like to exploit any vulnerabilities they can find, even if it is an app with a small number of users such as App Manager. App Manager has a very specific set of users which might entice them to find and exploit vulnerabilities in the app.

App Manager v2.6.5 and later are still supported and patches will be released if critical vulnerabilities have been discovered. Since the release of v3.0.0 has been announced, no new features will be added to the v2.6.x version lineup.

With the release of v3.1.x next year, we are going to discontinue support for v2.6.x as we haven't received any reports from v2.6.x for many months.

Now, unstable releases (debug, RC, etc.) should not be used for longer periods as they are not made to sustain and may break anytime, and I think we all can agree on this point. The question would be whether we should add an expiry date to the stable releases. Although we have set up 18 + 3 months (one year and nine months as the expiry date), statistics suggest that most users move to the next version of the app in much less time. A few others may not move due to the fact that they haven't used the app for quite some time.

However, there will always be a few people who would prefer an older version for no real reason. For example, a user told me that they still use v2.5.23 because the backup feature worked quite fast and asked me to revert the new changes and reimplement it. However, they failed to realise that the feature worked fast because it was not making a perfect backup of the app data which was fixed in the subsequent release and, thereby, slowing down the backup process. Now, backups can be made faster in many ways as put forward by some users and I gracefully considered their idea and design methods, and I am still working on a good solution to the feature. So, in this case, the former who asked me to support v2.5.23 was communicating their needs in a manner that cannot be done (a victim of the xy problem), and the latter users addressed real issues and possible solutions to the issue. (The latter is how anything develops and persists in an open source environment (or in a real society).)

I hope this makes things even more clear to you regarding this seemingly non-feature.

BTW, I tried to explain the use cases for users that have a disconnected phone like me.

What is the possible use-cases of App Manager in a disconnected phone (that is, a fully offline phone, not just using App Manager offline which doesn't really work in Android as you might be well aware)? The features offered and to be offered by App Manager are mostly for a connected phone.

[MuntashirAkon]

I think this is a topic for conversation over a beer, because I feel that nothing and no one will convince you.

This surely shall not convince me :)

[ignoramous]

It should not come as a surprise if you read my post in Telegram which explains how it is possible for an ordinary app to bypass sandboxing by utilising a certain permission, namely android.permission.INTERNET

To be fair, one can expand this logic to claim any and all sandboxing is broken (which very well might be the case, but such defeatism is boring even if earnest).

Android's sandboxing is already pretty nifty, and it isn't as water-tight because smartphone apps cannot exist in isolation. For instance, even if one removes the Internet permission from an app, the app may yet have access to write to disk or share documents over Storage Access Framework (SAF) with another app that may have access to the Internet... Is that weak sandboxing? Some may say so, but that's just a bad faith argument, because the user may very well disable that apps ability to write to disk or share over SAF...

If the point is to treat all apps with utmost adversity (and consider all permissions as sandbox leaks) then might as well not install any app on your Androids. If system apps are a worry too, then vanilla AOSP is an option; and if system daemons are untrustable, then might as well not use AOSP itself (:

A slippery slope is slippery...

[MuntashirAkon]

Added in c698ccf with the following limitation:

The dialog will still be displayed when user launches the app, but in stable releases, there will now be a continue button which will let users continue using the app without updating it.