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

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.

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?

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.

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

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.

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.

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.

n3t_admin

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

So - none, thank you. Yes, in fact it would.

tempproc 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.

If your car uses too much gas you don't go and rip out the radiator, right? Why are you trying to do the same with the OS?

tempproc 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 don't even know what to say to that. This is so wrong on so many levels.

tempproc 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.

Because it would increase your attack service. If for example a service would be always listening on a socket port 8764 and you disabled that, it could result in a malicious app doing the same and steal your data. Very abstract example, but a demonstration of the complexity of these systems. GrapheneOS wasn't built for tinkering. The premise is that the OS is safe as is and shouldn't be changed or modified. A little like the TOR browser, but for other reasons.

tempproc 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...

That is... wrong and shows that you haven't done extensive research. Every app could in theory create a work profile if you programmed it this way. And some do, like Shelter or Insular. Without adb or any special permissions. I don't even what could break if you disabled work profile, might be settings, might be a different user profile. I don't really know, because you need to look at the code for references and dependencies in the system.

tempproc 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.

From your experience. Now add to that 200k users with vastly varying setups (including those using work profiles) and you will have an influx of complaints or bug reports, as already seen with botched adb commands. This shouldn't be happening.

tempproc

n3t_admin

I understand your argument and the example of a service listening to port 8764 is a good one in that it shows that there is alternative with treating this specific gap.

Anyways even if there are dependancies, some can create various problems because of badly or purposefully badly designed apps or dependancies like a memory leak or constant request, but other work just fine.

For example disabling webcam service means that some camera apps will not show some options to livestream but still work perfectly right without any form of problem.

Some other will on the contrary make a whole app or service crash because an hidden dependancies that should be useless or separate is buffered at launched, which is the case for the Samsung camera app for example.

And I wish I didn't have all this tinkering to do but there's way to many packages that are not only useless (for most users), eat cycles for nothing on top of augmenting the attack surface or being privacy problems like Health Connect for example. There's no reason, that I know off why this can't be deactivated, and testing a few apps that use sensors for step-counters, it doesn't seem like it's dependent on it, and even then it wouldn't be a loss should a user chose not to use it.

n3t_admin

tempproc And I wish I didn't have all this tinkering to do but there's way to many packages that are not only useless (for most users), eat cycles for nothing on top of augmenting the attack surface or being privacy problems like Health Connect for example.

Since you are so dead set on there being "bloat" in the OS, I'll end my part of the discussion here, since you obviously can't be persuaded that the OS only has the necessary parts installed.

DeletedUser495

tempproc please, though you don't seem to realize it, don't ridicule yourself any further, there is no call for it. Just stick to facts.

Read https://grapheneos.org/ front to back (several times if needed) to get basic understanding how this OS works.

GrouchyGrape

tempproc others have explained it well. I'm simply going to add this.. No one is forcing you to use GOS. It sounds like it's clearly not for you and you can't be persuaded otherwise. It's not a "tinkerer's" OS. It's a privacy and security first OS. If you don't like the decisions made by the developers, don't use it. Or fork it and build it how you'd like it.

For me, I trust this OS more than any other.

BTW, most of what you're saying is not at all accurate (kinda sounds like you were taught by a LLM...). Like @DeletedUser495 said, please read the official documents so you can build a more reliable understanding.

tempproc

n3t_admin please, explain to me how Health Connect is not bloat?

tempproc

DeletedUser495 I did, but still not seing how some specifics apps like some that I mentioned are not unnecessary bloat or privacy infringing packages and yet can't be disabled

tempproc

GrouchyGrape That's a great idea, a "liter" version of GOS where unnecessary or snooping package are or can be disabled, I know I'm not the only one with this purpose.

Is there a repo of GOS forks, that actually might be interesting to see.

GrapheneOS

@lars Stop spreading all this blatant misinformation about GrapheneOS or you won't be participating on the forum anymore.

« Previous Page