New to GraphOS: Confused about the lack of control (Permission, Network etc...)?

tempproc

Thanks, I always conduct a per app research before doing anything with it. I hope there's no dependency for Wireless Emergency Alerts, but there sure as hell isn't for a lot of other preinstalled Android apps.

I think I'm gonna go the App Opps or Bender road as I'd like to avoid using shell.

23Sha-ger

tempproc I always conduct a per app research before doing anything with it.

tempproc I think I'm gonna go the App Opps or Bender

Perhaps conduct some more time to research what are the implications of using potential security issues like
Shizuku modules for managing apps:
https://discuss.grapheneos.org/d/20727-shizuku-new-terminal/2

But on GOS there is nothing to really "debloat". Because all the defaults do not access or send any data to 3d parties, minus the connectivity checks, but that's how the internet works, you need to ping a service and receive a reply to make sure you are actually online.

tempproc

23Sha-ger

I know those solutions augment the surface attack temporarily.

But having had Android for years and looking at running processes on GOS, I already saw a lot of them that are either useless and have no business running or to me, actually augment the risks, besides the storage, ram and battery life they nibble at.

Ammako

tempproc Or Wireless Emergency Alerts which was scourge on my old samsung and was actually exfiltering my files.

Elaborate? What makes you think your personal files were being stolen through Wireless Emergency Alerts?

tempproc

Ammako

The processes was ripping the battery and wending literally gigs of data out which I managed to somewhat sniff at the exit even though it was encrypted. There's no reason, no logs or informations that use that much.

It might have been highjacked or corrupted, but this just raises my case. I do no want an app which under the guise of safety is constantly active, overrides my settings and send god knows how much data out.

DeletedUser495

tempproc provide evidence for us to see.

tempproc

DeletedUser495

yeah I know that gaslighting, I have nothing to prove to you as wether Wireless Emergency Alert was acting suspicious is not the original question of the topic, which was how to disable packages and permissions on GOS.

I'll add to that that when I initialized the Pixel with GOS there was no temporary files and the apps accounted for around 300mb; it's now already shot past 400mb while there's 2go of temporary files: I haven't installed anything, no app is active, I haven't put any sim card or connected to any wifi yet...

This is why I want to be able to control what apps are doing and what the heck is happening in storage otherwise it defeats the "security and privacy" oriented purpose of GOS, but so far I'm billing at just being my ignorance and trying to understand.

DeletedUser495

tempproc just one of many, I can't be bothered looking for more

https://discuss.grapheneos.org/d/2317-system-app-permissions/2

n3t_admin

tempproc This is why I want to be able to control what apps are doing and what the heck is happening in storage otherwise it defeats the "security and privacy" oriented purpose of GOS, but so far I'm billing at just being my ignorance and trying to understand.

That's not necessary. Incredibly intelligent people have spent countless hours writing all that code and creating the OS that is widely known as AOSP. This includes everything under the hood, like RAM and storage management.

Meddling with these tightly integrated processes can have unforeseen consequences. The code is open and I would argue AOSP has some of the most audited codebases on the planet. If there were anything nefarious, it would have been very likely discovered by now.

Unless you know EXACTLY what you're doing, you will probably cause more problems than solve. You have control over the parts of the OS that are necessary. Everything else can be considered an autonomous system that should be left alone.

tempproc

DeletedUser495

Thanks I read it and agree with some of the answers: there's no reason for me to trust any system that I'm not a proprietary of.

I'm just not sure I understand GOS approach as even Google, Samsung, Xioami and not mentioning other rom distributions will in fact let you disable some of those apps, and package or permission disabling is part of most advanced roms.

I'm sure there's some tacite agreement with Google so that they remain open and collaborative with GOS.

But it'd be great if GOS really sorted the components and processes that are really actually critical and have function-breaking dependencies from a lot of those that really are not user needed. Hardened MTE or Malloc is great but other distribution are going to come-up with their Cheri/MTE implementation while integrating most user-requested features that could extend to SIM/ICCID protection, kernel-level or deep network monitoring, true kill switches etc...(until they get pressured I'm sure)

Well I'll test it for a while at least, but so far I must say I'm frustrated by this basic lack of control, right now there's 40 packages and their sub-processes running without any user prompted activity that are already using most of the ram, half of which are unnecessary or compromising, which even my previous Samsung or OnePlus didn't have this problem with.

tempproc

n3t_admin

My main reason for installing GOS is specifically to have control over AOSP as it onboards tons of bloat, and whether it's a matter of processing, memory, battery, security or privacy, a lot of those processes are not system-critical and should be disabl-able.

I'm already running out of ram and have my battery autonomy slashed in half without any external connectivity or activity besides settings...

Delaney

tempproc GrapheneOS is focused on security, not granular control for power users. It sounds like the goals of GrapheneOS do not align with your own.

n3t_admin

tempproc how did you determine what is bloat? AOSP is very barebones. Trying to remove bloat from AOSP is like removing airbags from a car to increase speed. Whatever you think is causing problems, is probably not it.
I also never had real issues with RAM or battery life. Which Pixel are you using?

GrouchyGrape

tempproc I'm already running out of ram and have my battery autonomy slashed in half without any external connectivity or activity besides settings...

This is guaranteed a configuration error or hardware (battery) failure. If you do a genuine audit of a fresh install of GOS, you'll find it does exactly what the developers claim it does and nothing more.

tempproc

Delaney it seems to be the case, I don't see how an OS with no transparency or control can equate a fully secure ROM. For example the Print Spooler which I do not use and is active despite every network and censor being inactive cannot be disabled or permissions changes despite being non-critical and a vulnerability.

DeletedUser495

So, first, in a regular stock OS you have way less control over permissions than on GrapheneOS. On top of AOSP it comes with more Google bloat and of course privileged Play services, which you can't really remove only inactivate and you're not gonna save yourself any storage by doing it (only by uninstalling updates).

Second, let me remind you, GrapheneOS was not developed for the tinkering likes of you, but to be run on production devices by general userbase and be as compatible as possible with additional third party applications users choose to install. Removing system services certainly doesn't help this compatibility.

And since you seem like you don't want to heed advice from people with a bit more experience with this OS, don't expect a lot of understanding and approval.

tempproc

DeletedUser495

I have never seen someone mention GrapheneOS while not being at the very minimum verse into "tinkering" especially when it comes to packages, and don't know of any department who would adopt a batch of GOS enabled devices for general users if they cannot check and "tinker" said packages or profiles.

As for the advices, I don't know which one you are referring too, since some components that are shipping with the stock OS are not critical, even when combing through hidden dependencies and yet are enabled with no user control.

tempproc

n3t_admin Im using a Pixel 9. And AOSP is far from as optimized or debloated as it can be.

I just made a test with all censors and sim visibly deactivated on airplane mode and no apps open. It lost 10% battery overnight off of a fresh phone and install with half of the RAM being used by various services like Health Connect or WebGL Angle which is a fingerprinting knightmare, although I believe those can be disabled.

tempproc

GrouchyGrape

I'm not saying this is not the case. It does indeed a priori what it claims and displays, the problem is that some packages that are running are non-critical and represent vulnerabilities, like the Print Spooler I mentioned just a comment before.

n3t_admin

tempproc again, what are your qualifications for assessing what is bloat?

What do you mean by disabling all sensors (censors?!)? If you turned off sensors for an app that needs it, it will most likely become a battery hog by retrying to access sensors and failing, over and over. Battery life also depends massively on app setup and which apps are running in the background. You can't completely stop apps from running in the background, except for disabling them.
WebGL ANGLE is not a "service", technically speaking. It doesn't consume any power. Health Connect will also not consume any meaningful resources that would show up in a noticeable manner.
Your battery dropping by 10% over night could be anything, down to the pretty inefficient Tensor chip.

tempproc

n3t_admin

Well it would be difficult to know without the ability to disable and test for it wouldn't it?

And what you're mentioning about apps hogging battery by making requests can be in fact fixed by disabling those packages, unless there's hidden or tangled dependencies.

Now comparing the battery consumption of stock Android on custom Pixel packages (with ADB) and unmodified GrapheneOS I can definitely tell that there's unnecessary bloat running and that's normal if it's based on AOSP with extra-security layer running.

I just don't understand from reading a dozen threads on here or reddit specifically talking about finer packages and processes disabling features why would a custom ROM actively try to prevent user from doing that, again unless we're talking about critical packages.

I don't buy the infantilizing and slightly creepy controlling argument that it's "for your own good, don't ask or try to choose what you want to run on your device", especially when it includes apps like Health Connect or has Work Setup running when the base OS doesn't support/need Work Profile unless using sandbox Google Play services and adb...

Whether from an attack surface, privacy, or performance/battery POV I don't see why it should be running by default in the background and in my experience disabling it when no Work Profile is used doesn't interfere with the OSs operations in any way.