Testimony during Google’s antitrust case revealed that the company may be altering billions of queries a day to generate results that will get you to buy more stuff.
I can't say I don't use Google as I own an unrooted pixel on the Fi network but I've done what I'm able to lessen the information given to them by stopping the use of the search engine, browser and sandboxing any Google pages in my FF browser. It started bothering me how much I was relying on one company for nearly everything online.
My next phone will likely be rooted and running a different OS.
Pixel is still one of the best options overall despite other Google enshittification. There are plenty of ways to move away from Google defaults without changing the OS. If that's not enough, you'd still benefit from their software support. Third party OSes like LineageOS and Graphene can use Google's updated sources and binary blobs for driving the hardware during the same 5-7 year support lifespan. As a result those OSes should be able to run securely on a Pixel at least till the end of its official support span.
The rooting process itself often involves running an exploit and trusting whoever wrote the rooting tool not to use that exploit to do anything undisclosed. If you wanted to install an undetectable rootkit, slipping something into such a tool wouldn't be a bad way to do it.
The rooting process itself often involves running an exploit
It most certainly does not. Exploits were used a decade ago, nowadays you unlock the bootloader using a manufacturer-provided key. And regardless of the key you need physical access to the device and rebooting into a special runtime.
You just answered your own question. How many users click approve without thinking? How many install Xposed modules that intentionally, or unintentionally, create security issues?
I didn't say rooting will break your security, just that it can. Rooting exponentially increasing the attack surface, which for some users isn't a concern, but for your average user, it probably should be.
In this case, this person wanted to increase his privacy, which is why I recommended what I did.
Also, FWIW, there's a reason why GrapheneOS and DivestOS specifically design their ROMS to NOT be rooted and to RELOCK the bootloader.
Saying "rooting can harm the security of your device significantly" is like saying "crossing the street exposes you to mortal danger". It's technically true but fails to take into consideration a huge amount of factors, to the point it loses all meaning. Either qualify your statements or refrain from making such generic ones.
You just answered your own question. How many users click approve without thinking? How many install Xposed modules that intentionally, or unintentionally, create security issues?
You do realize that most of the Internet runs on servers where people have admin access? And there's no shortage of attacks against machines on the Internt. If they can manage to function under these conditions I think my phone will also be fine.
I'm pretty reliant on a couple of big providers I find. Usually Amazon is my first search stop then Google. I find I need to disable my ad blockers to be able to use the sponsored links. I often am searching for a solution product not a specific item so I'm curious about the options. Then I narrow down into specific items which Google does a pretty good job of I find for me.
I was an early Google adopter so I've been using Google for a lot of things over the years.
I often use search within Google Maps to find locations hours, reviews on a experience, and a location or business' website.
I've recently switched to Duck Duck Go and FF and I find it might be a familiarity to the types of localized results I miss as I'm still pretty plugged into the Google eco system and duck duck go doesn't seem to hit the mark as closely for me.
How does rooting "cripple" security? You still need to give Superuser permission to apps on an individual basis. So long as you only give Superuser permission to widely-used open-source apps, what's the "crippling" change?
Or do you mean having an unlocked bootloader, which gives anyone with physical access to your device tools to unlock your phone? That's related, but different, from rooting. And you can lock your bootloader and keep root access, so they aren't interchangeable.
you can't lock your bootloader and retain access for one. that's an easy way to brick your device. it cripples security because in order to gain this access you are patching in the sudo binary (which doesn't normally exist on Android and is therefore not designed to be securely used) and a bunch of selinux policies that give extremely vague permissions systemwide. data exfiltration is made a much simpler task when a user has rooted their device.
it is also increasing attack surface. you now have to trust that this per app permission model is actually functioning correctly and isn't exploitable.
edit: it is worth noting that having root access on a desktop Linux system is horribly insecure as well, though. I completely remove sudo on my systems (although considering one can just invoke su -c or su - root that doesn't help too much in actuality)
edit: it is worth noting that having root access on a desktop Linux system is horribly insecure as well, though. I completely remove sudo on my systems (although considering one can just invoke su -c or su - root that doesn't help too much in actuality)
You have just proven you never or very rarely use a computer. How do you even update the system without sudo or an alternative to it?
Without root permissions you basically can't manage your system anymore.
su - is actually the traditional way of getting superuser permissions on a Linux device—enter your root password, and it gives you a root shell that can perform all administration tasks. I've never even had sudo installed on my systems, because it doesn't improve security for my specific use case. (How relevant is this to the various Android-device-related points? Not at all, really.)
one of the reasons I use nix package manager is because it doesn't require root. it has separate build users and a daemon responsible for privileged file management. I also have a separate user with access if I absolutely need it, or I can log in with a live session and chroot into my system.
if you need root for a general purpose application then it's badly designed
a better solution than giving blanket root access would be an API/daemon that provides more fine grained permission control, similar to how flatseal manages the flatpak sandbox.
edit: anyone wanna help me on a new project idea...?