Universal-Debloater-Alliance / universal-android-debloater-next-generation

Cross-platform GUI written in Rust using ADB to debloat non-rooted Android devices. Improve your privacy, the security and battery life of your device.
GNU General Public License v3.0
2.41k stars 84 forks source link

feat(pkg-list): Add a `Safe` removal list #583

Open Rudxain opened 2 months ago

Rudxain commented 2 months ago

Describe the feature you want

https://discord.com/channels/1168607797081022514/1168607798196715573/1273024610035564595

We should split Recommended in 2 variants:

Alternative solution

We could move some packs from Recommended to Advanced, but that seems misleading, as removing Recommended packs should never break the system in any way

Prior art

There's precedent for this: uBO does something similar: malware/badware & ads are filter-lists that are enabled by default, but "annoyances" is disabled by default because some users want what others consider "annoying"

Acknowledgements

jacklollz2 commented 2 months ago

I was just about to recommend this. Some of these "Recommended" entries are not for the average user, like removing Gmail and such. I want a list where I can just check everything, and run the script. No hassle.

Rudxain commented 2 months ago

I've been considering another alternative solution, which seems more complicated but could pay-off in the long run:

  1. Move all Advanceds to Expert
  2. Rename Advanced to Safe
  3. Move all Recommendeds to Safe
  4. Gradually (opportunistically) move some Safe packs to Recommended

The 1st 3 steps can be automated, but the last one requires human effort

Frigyes06 commented 2 months ago

I agree with this. I think these packages make it into recommended because most package list maintainers (rightfully) think that they are bloat/spyware. If I understand correctly, you're proposing a list that includes only packages the user is unlikely to interact with, therefore won't likely need, and only include packages that are highly unlikely to break any other functions?

Rudxain commented 2 months ago

If I understand correctly, you're proposing a list that includes only packages the user is unlikely to interact with, therefore won't likely need, and only include packages that are highly unlikely to break any other functions?

Yes! But those are just a few of many factors to take into account when deciding the recommendation category.

For example, a Recommended pack could be so malicious, that even if it does break the system when removed, it would be worth it. However, if the breakage is too much, then the "evilness" cancels out, so it should be in Advanced instead.

It could be said that my proposal/RFC only adds 1 or 2 more factors to decide the recommendation, but those factors were already being considered since a long time, so only the categories/recommendations would change

AnonymousWP commented 2 months ago

This sounds like an okay feature, but we need to investigate how to implement this, because it's also prone to subjectiveness. Also, our top priority for now should be 1.1.0 and the current open PRs:

So in my opinion we shouldn't focus on this yet. First things first. 😉

Rudxain commented 1 month ago

Should we close #640 as dupe of this?

crash5 commented 1 month ago

I would like to suggest a "name" key to store the app name in the uad file too. For example, the "Bolt: Request a Ride" app package name is "ee.mtakso.client". Which is pretty hard to figure out without additional googling. Some samsung packages has the same "sane" naming too :)

Rudxain commented 1 month ago

"name" key

I agree, but there's multiple names:

We still haven't found a proper way to show the display-name and app-icon of installed apps

AnonymousWP commented 3 weeks ago

Will be done together with https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/discussions/646 and https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/discussions/608.