App Manager build expiry date and compatibility warning

[MuntashirAkon]

App Manager uses a lot of privileged permissions and execute a lot of privileged instructions. Therefore, it is necessary to ensure that the users are using the latest version of App Manager to keep up to date with the latest security updates. App Manager also executes a lot of private APIs that often change in a new Android release. Keeping these two issues in mind, I am proposing two new features: Build expiry date and compatibility warning.

Build Expiry Date I now and then receive crash reports from very versions of App Manager such as v2.5.24-PRE or v2.6.5.1. Had they been warned about the potential security issues with the version that they were using, they might decide to update the app. Having a fixed lifetime for a specific build can fix this. For example, a debug build may have at most two months lifetime, after this time, the user could be warned to either update or uninstall the app for a week or so, and completely stop working after that. That is, every build would have a fixed date associated with it after which it will warn for a few days after completely stop working. My proposed timespans are as follows:

Build type	Timespan (months since update)	Warning period (after which the build will stop working)
Debug	2 months	2 weeks
Alpha	6 months	1 month
Beta	6 months	1 month
RC	6 months	1 month
Stable	18 months	3 months

This also means that I have to provide updates between these periods, which I will do if I am alive and not serious ill. If I cannot provide update within these periods, it means that the users should abandon the app until a new update is available. This, I think, is okay because security is very crucial these days, and people should never use sensitive apps such as App Manager unless it is well maintained.

Compatibility Warning By compatibility, people usually mean backward compatibility. However, this isn't the case here. By compatibility, I exclusively mean forward compatibility.

App Manager uses a lot of private APIs that aren't supposed to be used by any third-party app according to Google. However, Google often makes wrong decisions when it comes to protecting users privacy or usability, so we have to use these APIs nonetheless. But the drawback of using these APIs is that they might change in a new version of Android without explicitly documenting anything (at least, not publicly). This might cause App Manager to crash on that version of Android. Therefore, it is necessary to warn users of potential compatibility issues if they are not yet supported by App Manager — either partially or completely so that instead of complaining about it, the users will report such issues so that we can figure out what causes it and how to fix them.

[ignoramous]

+1. WhatsApp and Signal do this.

It isn't as trivial though. You'd need to trust the time sources and whatever the Android Package manager is telling you. Apps like Tailscale burn in time-of-build into the binary. Even then, these binaries could be meddled with, but at least, the sigs would change, where Android already its bases covered.

As for time sources, we need this for RethinkDNS ourselves. Right now, our plan is to impl Chromium's roughtime protocol on our servers and pin those certs in the app.

[MuntashirAkon]

It isn't as trivial though. You'd need to trust the time sources and whatever the Android Package manager is telling you. Apps like Tailscale burn in time-of-build into the binary. Even then, these binaries could be meddled with, but at least, the sigs would change, where Android already its bases covered.

As for time sources, we need this for RethinkDNS ourselves. Right now, our plan is to impl Chromium's roughtime protocol on our servers and pin those certs in the app.

Thanks for sharing your insights. I think the requirements/threat model of WhatsApp and Signal are quite different from App Manager in this regard, especially because these apps exclusively rely on the Internet (albeit they trust Android too much, I believe). They need to protect servers, clients and users. But I confess, I am not familiar with the attack vector here. As specified in the first post, the build time shall be included in the app, but yes, time sources play an important role here, therefore, a possible attack vector. We can utilise a SNTP server as I've seen in some libraries (but without authorisation, as argued by the Graphene OS devs, SNTP is also useless). I, of course, shan't pay much attention to signatures because if signature verification is turned off (e.g. by the application of CorePatch), the security of the OS is already broken. (There also appears to be certain side effects of CorePatch as some users have suggested.) Let me know how it goes.

[MuntashirAkon]

7b06f346f70d81cd91a34eb221d1b736ab017849

[Efreak]

It should be possible to disable this function in settings if you implement it, some of us use devices that aren't connected to the internet, or with most services firewalled. If few apps can go online, then there's nothing wrong with running an outdated version of the app.

My use case: I have an old phone with no SIM card connected to my stereo, running BubbleUPnP (use case same as Chromecast audio). Afwall+ allows only BubbleUPnP and a few other apps to access the internet. The system itself is allowed to access the network for things like time synchronization, as BubbleUPnP needs to be able to go online to play from services like YouTube, and other URLs in playlists.

If the time is incorrect, it can cause certificate validity errors with https; while I used to run BubbleUPnP server on my desktop (which might deal with this), half the reason I have this setup is to make it fully standalone so I can turn my PC off when not in use (BubbleUPnP is an openhome DLNA renderer, so I can disconnect the controller, too)

[MuntashirAkon]

@Efreak: Use #954 for commenting regarding the former issue.

[MuntashirAkon]

The second part of the issue is abandoned as I was able to reduce the number of crashes due to forward compatibility issues.