Earlier quoted context omitted.
That's not a reason. When the hardware doesn't have those "security features", then don't "really secure", just run without being "really secure". I never treat my (Android) phone as secure anyway.
Security is GrapheneOS's raison d'être. If you don't want security, you can run another Android build that does run on the hardware you have.
Android Developer Verification: Threat masquerading as protection
641–650 of 793 posts
Re: Android Developer Verification: Threat masquerading as protection
#642Earlier quoted context omitted.
Being an administrator is being root. That's the entire point. That whatever restrictions an app has set, I can override it if I need to. > You can build and sign the OS with your own keys, without undermining the security of your device, and adding whatever functionality you want with the principle of least privilege. Building a version of the OS and flashing that removes everything currently on the device. So if I…
You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands. Installing your own build does wipe the device when you unlock the bootloader, yes, but updating it with a locked bootloader does not. It would be a one time transfer if you have official images already installed…
Okay, so once I install grapheneOS, how do I update it with my own custom build while keeping my data intact?
> You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands.
You haven't read anything of what I've written, it's incredible.
You're continuing to use the term "root" to mean granting full power to random apps.
I'm using the term "root" in Linux terminology.
It's not advisable to run random software as root, no matter what platform you are on.
But the OS' native file explorer and shell, in this case com.android.documentsui/com.android.files and adb, should allow the user to authorize themselves as root and read/write to any file.
Re: Android Developer Verification: Threat masquerading as protection
#643Earlier quoted context omitted.
All of which have beyond horrific security. GrapheneOS is the only acceptable alternative from mainstream Android.
Don’t they have standard Linux security? Does my phone need to be more secure than my production web server?
Those ports of desktop Linux to mobile don't have a proper privacy/security model for running applications. They don't have anything close to modern exploit protections or hardware-based security features crucial to protect against increasingly sophisticated and widespread exploits. AOSP is a Linux distribution with drastically improved privacy and security compared to a traditional desktop Linux traditional. GrapheneOS starts from there and improves privacy and security much further.
Re: Android Developer Verification: Threat masquerading as protection
#644Earlier quoted context omitted.
To avoid this, I tried to close my Google Play Developer account. A decade ago I published a free app on it, which was online for half a year. It was to no avail. They will not close the account. I received only automated responses about bringing my old app into compliance with current policy, to then transfer it to another developer account. Only then would Google graciously allow me to close my Developer account. M…
I tried to close my account, and got the response. But they closed it when I failed to verify it.
Re: Android Developer Verification: Threat masquerading as protection
#645Earlier quoted context omitted.
Don’t they have standard Linux security? Does my phone need to be more secure than my production web server?
There isn't a standard Linux distribution. Those operating systems have drastically worse security than a decent server distribution or the mainstream mobile Linux. Traditional Linux distributions don't have a standard set of core components or configuration so system administrators are assembling their own OS and the differences in security are vast. It's extremely rare to deploy anything close to the level of iOS a…
Huh? Of course they do. A standard set of components and configuration is at the core of (most) OS distributions.
Re: Android Developer Verification: Threat masquerading as protection
#646Earlier quoted context omitted.
Which phones are supported by which of these operating systems? And can you provide some relevant links?
- https://sailfishos.org - https://docs.sailfishos.org/Support/Supported_Devices They have few devices of their own (new one coming out this October) and they officially support many Sony Xperia devices. There are also many community ports. - https://ubuntu-touch.io - https://devices.ubuntu-touch.io They have 33 supported devices, some are being shipped directly with the OS or have an official agreement with the phon…
Privacy depends on privacy patches/protections and on security patches/protections. They do the opposite of taking it seriously from the hardware through the software.
None has anything close to the privacy or security of AOSP or iOS. Librem 5 is the direct opposite of hardware prioritizing privacy and security. It doesn't provide basic firmware updates, uses a bunch of extremely low security components and brings the awful privacy and security of a desktop OS to mobile on top of that. It's the opposite of how you're describing it. Purism's devices also aren't open source as they claim but rather are closed source hardware with closed source firmware. They only pretend it's open hardware and firmware by not shipping the closed source firmware with the OS, which leaves users without crucial privacy/security protections. The components don't have proper updates available regardless due to their hardware choices but they don't ship what is available and prevented doing it for some components.
> They target devices made with the intent of running linux, but also have a few ports to android devices.
AOSP is a Linux distribution. Linux doesn't mean glibc, systemd, GNU coreutils and GNOME. If you mean GNU/Linux or bringing systemd to mobile then that's what you should say.
Re: Android Developer Verification: Threat masquerading as protection
#647Earlier quoted context omitted.
In a town nearby me (not really near me but within an hour's driving distance), sometimes I will see old people selling fresh fruit/vegetables in their front yard. They typically take cash, Cashapp, or Venmo. It's super convenient to be able to use Venmo in that situation. These are people I haven't met before.
I usually pay with cash. As a nice bonus, cash works even if there are mobile Internet shutdowns or blackouts and they cannot block the cash in your wallet unlike a bank account.
That part is shrinking however, so you need a plan to cope with that situation sooner or later. Not doing business with others and growing your own food does not suffice as a plan for most people.
Re: Android Developer Verification: Threat masquerading as protection
#648It doesn't solve the current issue, but in case we don't manage to push back on this, some people might not know that there are various actual linux OSes for mobile: - SailfishOS: still linux based and seems fairly community inclusive, but the UI part of the stack is closed source. Is the only one officially allowed to run android apps, via emulation. Has existed for a very long time, it's lightweight and I think the…
Usability-wise, they are no match for Android and iOS—or even versions of them from five years ago. UI/UX is costly, and most FOSS projects cannot get it right without massive investments from enterprises (e.g., Red Hat's UX designers heavily contributed to GNOME) or startups (e.g., Zed, Element, Bluesky). Projects without that backing are mostly unusable, at least from a Gen Z perspective.
Re: Android Developer Verification: Threat masquerading as protection
#649Earlier quoted context omitted.
There isn't a standard Linux distribution. Those operating systems have drastically worse security than a decent server distribution or the mainstream mobile Linux. Traditional Linux distributions don't have a standard set of core components or configuration so system administrators are assembling their own OS and the differences in security are vast. It's extremely rare to deploy anything close to the level of iOS a…
> Traditional Linux distributions don't have a standard set of core components or configuration Huh? Of course they do. A standard set of components and configuration is at the core of (most) OS distributions.
Linux distributions use different implementations of init systems, shells, command-line tools and nearly everything else. Ubuntu uses glibc, systemd and Rust uutils coreutils. Alpine uses OpenRC, Musl and BusyBox as the defaults. Debian uses glibc, systemd and GNU coreutils as the defaults but supports other choices of init system. Each has their own variants of the projects they each package with different versions, patches compile-time configuration and default runtime configuration.
Using systemd, Bash, etc. on an OS Debian is a choice for the system administrator rather than the OS being defined that way. Even if people swap out major components for ones which aren't officially supported, it's not generally regarded as not using the distribution anymore. It's a far different approach than defining a standard base OS, developing that together as a whole with user installed packages and configuration changes are solely on top of that.
The higher up you go in the software stack, the more different things are across operating systems. The Debian installations across different machines are a vastly different OS with far different components and configuration. There are default sets of packages and configurations but not a standard base OS shared across each machine. Swapping out components and changing the configuration isn't making it not Debian and is pretty much required.
A huge portion of server Linux uses musl and BusyBox due to Alpine.
Embedded Linux has always heavily used different software stacks. Android wasn't much different in that regard on mobile. Android runs fine on standard Linux kernels without any mandatory downstream changes. It was never the only distribution making changes to the kernel regardless.
Re: Android Developer Verification: Threat masquerading as protection
#650Earlier quoted context omitted.
Which phones are supported by which of these operating systems? And can you provide some relevant links?
- https://sailfishos.org - https://docs.sailfishos.org/Support/Supported_Devices They have few devices of their own (new one coming out this October) and they officially support many Sony Xperia devices. There are also many community ports. - https://ubuntu-touch.io - https://devices.ubuntu-touch.io They have 33 supported devices, some are being shipped directly with the OS or have an official agreement with the phon…