Classic slippery slope fallacy.

https://en.wikipedia.org/wiki/Slippery_slope

History shows that when a "slope" appears... regulation steps in, technology evolves to solve the problem, or the culture shifts to reinterpret the thing.

In almost every case, the feared "bottom" of the slope was never reached because humans constantly built ramps or bridges along the way.

The claim is that a repeat monopolist is doing monopolist things. Feel free to make the case for the trustworthiness of Google's opposing claim, as I don't see anyone else doing that.

Google has stated that this is about sideloading apps and has only talked about the sideloading flow being changed. Removing already installed apps is unrelated to the sideloading / package installation flow. Google has not stated anything about deleting apps from unverified developers so I am confident it won't happen. As I mentioned there already is a component in the system responsible for removing malware.

>Where do we read the warranties that no disaster will happen involving my_private_app.apk?

There is no warranty similar to how there is no warranty Google will make your phone summon nasal demons.

>Is there any place in which the crucial, critical information about this new idea from Google, duly FAQ, is found?

It will eventually be in an apk on the device and once someone dumps I would be willing to reverse engineer it and explain its functionality free of charge.

It requires a lot more steps to do this. Finding another computer, installing Android dev tools, finding a cable to connect them. In reality this adds a lot of friction.

>How do you know nothing will happen to already-installed apps and their data, when the user hasn't had time yet to go through the annoyance unlock procedure?

Extrapolation based off how play services has handled things so far and how Google has explained what will happen. Of course without looking at the actual code I can't say for 100% certainty, but from my perspective fdroid is fear mongering here as there is no evidence that supports this viewpoint. If they had evidence to back these dramatic claims up I would be less critical on them.

I do not need Google Play (a collection of spyware, covertly collecting Wifi points and cell towers location in my country and sending them abroad), I do not need bank apps (I have a laptop for that) so I guess I will be fine. Obviously there will be no developer verification on my device as well, and I mostly use apps from F-Droid anyway.

Good thing about F-Droid is that they build apps themselves and you can always get the sources - unlike Google Play and Apple Store that provide no sources and unlike PyPi/NPM which allows sources to not match the binary distribution.

24 hour waiting time? Big outcry.. Anticompetitive permission system where apps can do not that much more than websites? Nah, it's fine..

Unless you unlocked the bootloader, you were NEVER able to install apps you want, as Google had the final say what those apps could do (the anticompetitive permission system where user is the third class citizen, vendors are second-class citizen and there's only one first class citizen - Google). We need to fight for the right to unlock the bootloader and then not be restricted by the actual malware that is Play Integrity.

If Google is looking at a world where all of their competitors are using first-party-controlled signing, it makes sense for them to wonder "why not us". And if they get sued for this, that would set the precedent for all of their competitors too.

At that point the playing field would be level and platforms would be properly open.

Is that right? Is that the future of Android as well?

Could one stop this by disabling OS updates?

On my android phone:

My own launcher

My own keyboard

My own sync tool for local net

My own net tools to WoL some devices on my lan.

My own tool to control 3 proxmox servers

My own tool that parses groceries slips

My own tool that keep tracks of my vehicles events/lifecycle/purchases etc.

If they break my launcher/keyboard and my ability to use my phone in my customized way, they will NEVER see me as a client again. None of these apps are in the Play Store, they are signed with my own signing keys, which have never been uploaded to google, in fact, no google account is linked to these apps. These apps are also privacy-oriented (even the keyboard, I ship a 1mb dictionary with and it learns my own words, never transmits anything).

I will not give google my ID , neither Persona or anyone else. I'm very happy to go back to using bank card + chip + pin than use google wallet. Trust me I will walk away. I already move 4 family members off of Windows in the last 2 years, I will get them off google too.

Now that they reached penetration they do the switch - under the guise of security.

Just let me do with my hardware what I want to do it. Let it be my responsibility to install whatever I want (and stop calling it "side-loading", as if I am doing something shady from the "side").

We need to resist this! Alas, from the broader response it seems that most people just do not care.

If this is disseminated through Play Protect, does disabling Play Protect prevent triggering this?

It's not your phone, it's the corporation's phone, they're only generously allowing you to use it, on their terms. If you install GrapheneOS, or any other system that you gives you ownership of the machine, from the bank's perspective you turn into a fraudster, from the video game's perspective you turn into a cheater, etc.

[1] https://droidify.app/

- https://en.wikipedia.org/wiki/Don%27t_be_evil

It didn't.

Phishing is just a pretext. Google didn't care about Phishing for the first 20 years of Android. Why do they now? Because it serves as argument to close their platform a little more (which is a trend that has been going on for years).

those people fall for this because for everything poor people do, they need an app that is provided by sleazy vendors and that require tons of permission, and face scan and what not. they were primed so those business could save in operating costs.

that's the problem. won't solve it with slightly less sleazy vendors.

The scam apps are already in there. Please stop repeating google's propaganda.

Again, there is a tradeoff between protecting consumers and protecting vendors. If you protect the privacy of vendors, you do so at the expense of increasing risk to the consumers.

I don't want to be polarizing, but narcissistic is the best word to describe the position of this article. I'm assuming that when they are consumers, they would find it reasonable that their vendors provide due diligence and be held to higher standards. When they go to the pharmacy, and they buy aspirins, would they choose a tablet of aspirins from a pharmacy that doesn't ask where the aspirins came from or who the distributor or producer is? If such privacy of the producer were respected then the market would open up to actors that provide low quality, counterfeit, or malicious product.

You can't have it both ways. If you are a vendor, you are no longer an anonymous consumer. Installing a VPN, paying with cryptocurrency, using firefox and duckduckgo to avoid tracking, that's not on the table for you once you decide to be on the other side of the production market.

If you want to make software and distribute it anonymously, go ahead and submit it to one of the many malware riddled distributors that don't do any due diligence like npm, github, AUR, why must you insist on being let in a club that doesn't want you? Is it perhaps because the reputation of such club is higher because it doesn't have malware because it performs such due diligence?

At least if you are going to complain about this, do it with standard language don't co-opt cybersecurity terms, adding noise to whoever cares about actual security. If this is really a problem you wouldn't need to exaggerate or plain lie about it.

Are governments going to institute more lockdowns? Is this some topdown control thing?

I will root this POS android phone I have and forego any Google Play services and just use it as web browser and a phone. Fuck these guys!

I personally have seen every single older relative and non-tech friend, end up installing bloateare, spyware, and malware inadvertently - because they have no idea how anything in the tech domain works. And given the widespread popularity of Android (globally 70% vs iOS at 30% market share) and even moreso in lower income demographics, it also leads to rampant piracy of obviously non-essential apps like games and streaming (eg Spotify). In fact, even here on HN, almost everyone who has given their parents an iPhone has extolled the virtues of a secured AppStore/device and the peace of mind it brings.

While there may someday be a way to support both the average user and the HN power user, we are not there yet. It’s hard for me to outright reject Google/Android attempts to secure people’s devices.

And you’ll never reach a human to sort it out.

About Google squeezing profits out of everything, yes but that's a kinda new thing, mostly starting 2023. They did their first mass layoffs ever, then started cutting costs and milking products more. I'm not saying they were better before or something, it's just that it was growth time before. That was also the same time they started talking about locking down Android, and even WEI.

My app has already been removed when they added the Privacy Policy requirement for the Advertising ID, where I did not update the app.

Why would you not trust Jolla? It was born from Nokia employees. GrapheneOS is a great alternative. Still Android though.

Google thinks they own my phone. They do not. I do not consent to this change, and will be voting against it by using the only remaining option: Moving completely out of their ecosystem.

They really left me no other choice when they decided that they didn't need the owners consent.

It's app store security vs app store security with verified developer IDs

The fact that the android fraud is not endemic means that the later is not worth the increased risk of losing your Google account.

The attack in question doesn't use apps on the store, or even any attempt to get them on the store. There are also other attacks, but the one that prompted this change uses social engineering to get people to tap the build number seven times, sideload something and get a keylogger that then picked up their banking details and used them. Several governments raised the issue, Google acted. (The actions are to slow down the tap-seven-times process, so it becomes harder for the scammers to keep their victims fooled until the keylogger is installed, and also to tweak the timings, so the scammers can't outrun the app-banning process.)

If you haven't had your bank account drained, the scammers you met were different ones. (And I'm sorry that you've been scammed.)

I’m not even being cynical — it would probably just increase the amount of government contract cash awarded to them. Control makes governing a lot easier, control is what tech companies have, and to varying degrees, it’s for sale.

Governments are made up of people. People who have at best median level understanding of the things they are ruling about but great self-interest in following the biggest purse to which they can attach themselves.

[1] https://forum.sailfishos.org/t/banking-apps-on-sailfish-os/1...

Kicker? The photos were requested by a doctor.

Ref: https://www.koffellaw.com/blog/google-ai-technology-flags-da...

I have seen people being locked out as early as 2011 of accounts that could only be unlocked by sending a copy of an ID. Due to regulatory change of saving of information based on age (first 13 and above was ok, then became 16 and above).

If you are wrongly charged a significant amount by either Google or Apple and their service is of no help, what would you do?

Most people would weigh the options, then just eat the cost than anger them with a chargeback and lose their email/phone access. That's self-censorship financially too.

What if Google reinstates their old G+ and YouTube real name policy for its accounts. We would protest but give them the proof grudgingly and it can position itself as one of the core part of online ID verification push currently going on.

„Power tends to corrupt, and absolute power corrupts absolutely.“ - Lord Acton, 1887

We need corporations and governments to stop locking down and gatekeeping vital software to closed ecosystems.

A Linux phone doesn't help me when my government's 2FA system (BankID) only runs on Android and IOS phones and can only be acquired with an app store account.

Now, my card info did in fact get compromised recently, and that's probably why I ended up needing that stronger auth flow. But the fact that I literally can't complete that stronger bank authentication without Google or Apple is... yeah. No.

I have since signed up for a different credit card that I plan to use from here on out.

I mean, tbf the situation was fine until the US transitioned to an autocracy, and the companies went full surveillance state evil, completely supporting the autocracy. Which is a relatively recent development.

But sure.

Most places here are working as fast as possible to decouple from any reliance on the US, and I would expect Norway to switch to the new EU digital ID system currently in development.

They removed SMS 2FA options recently, the only non-tech monopoly method is a 2fa codebrick that's getting harder and harder to acquire (there are new ridiculous facial ID and passport scanning requirements, run by a private corporation, in order to get one).

It's garbage and getting worse. And it seems no one cares our entire lives exist at the whim of two US tech monoliths.

I cannot install any iOS software without being logged into my Apple account, not even an alternative app store.

It would be perfect on my older iDevices, but they don't let me log in anymore “because the OS is too old”. And guess what: I cannot update the OS without being logged in. I never logged out of those iDevices, Apple did that from their end.

Only users based in Brazil, Japan, or the European Union are able to install apps through alternative app distribution. The country or region of your *Apple Account* must be set to one of those countries or regions, and you must physically be located there. [0]

UPDATE: Also tried to install onside.io. No luck. The same popup:

Cannot Install App: You are not eligible to install apps from "onside.io".

[0] https://support.apple.com/en-us/117767 https://support.apple.com/en-us/118110

And a president could always just call up the CEOs and ask for their least favourite Norwegian to be cancelled without any paperwork.

If a bank or government requires use of a "smartphone app" then this does not mean this smartphone must be used for any other purpose(s)

Nothing forces someone to install the app on every smartphone they own

These required apps do not prevent anyone with multiple smartphones from using alternative OS, i.e., not Android or iOS, on some of them

Also, how’s isolation on LineageOS for mobile apps? I think I’m getting to the point where I’m thinking of ditching Apple again

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.

E.g., on the XPERIA 10 IV, the camera and mic doesn't work, which makes it hard to use as a phone:

https://forum.sailfishos.org/t/functional-state-of-the-xperi...

Perhaps the antiquity of the US banking system is finally coming in handy. I’ve still got my checkbook ready to go!

Many services won't work at all.

It's as hostile as they can make it because people apparently keep buying that, even when there's no semblance of the freedoms we have on Android, Windows, Linux, BSD, etc. Google saw that this suffices for the EU and does half a step towards it and people are, unsurprisingly, appalled because the whole FOSS community is here now. I still think it started with Apple demonstrating how successfully hostile you can be in a duopoly where the cards have been dealt.

Few commercial entities will happily re-implement their apps for a third, new, upcoming platform. Google and Apple will never get outcompeted so long as their software ships on the hardware that people want. Even Microsoft (Windows Mobile predated both OSs) threw in the towel, I wouldn't know who else stands a chance. Regulating these entities seems the only path when Google has evidently decided there's no point trying to compete on openness (also demonstrated by the widespread acceptance of GrapheneOS in the FOSS community: people would rather be kept safe than be free - https://news.ycombinator.com/item?id=48758146)

And the setting is "optional", just do the 24h-waiting song and dance to change it, or use ADB. /s

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.

Confirmed, he says it in video: https://x.com/GrapheneOS/status/2040887784253141142

But yeah, vendors maintaining their drivers upstream in FOSS projects would obviously make it easer

That still wouldn't affect projects like Debian or Arch, but going even further, they can't push through updates anyway. Nothing forces me to install updates, it's an active choice to do so.

In the meantime we might try think of a solution.

Having gained their market share, Google now pulls a bait-and-switch by quietly retreating from Android's "open" messaging and philosophy. That's too bad for Google, because a mere appliance, it's worse than iPhone in every dimension.

That should *not be a thing*.

You bought the device.

You own it.

It should be yours to do with as you see fit.

That applies to phones or appliances or cars unless your individual right to modify your devices begins to interfere with the rights of others (think: safety, tragedy of the commons scenarios, etc).

This is how we end up with cars we can't repair, phones we can't upcycle, TVs that advertise to us without our consent.

Its insanity.

To "write", I mean the precursor to "read".

https://www.gnu.org/philosophy/right-to-read.en.html

> Are you talking about literature / articles, or software?

All of the above.

> This is new to me, want to stay on top of it.

I am sorry to tell you it is not too new. Google tried this before recently with something called WEI (which you might be able to find on ddg or other search engines): It failed for reasons few people know for sure[1], but the initiative had the same basic bullshit about security, and the same outcomes.

[1]: The story I heard was a couple South-American countries noticed that this would prevent their people from being able to work on software that runs in the Google ecosystem and threatened to block Google en masse. Since then, one of the countries that Google has a lot of offices in invaded one of those South American Countries for conveniently unrelated reasons.

Which device you need to be more secure depends on your needs and which device you put sensitive data on, but a mobile device is going to provide far better privacy and security than any desktop hardware or OS is currently capable of.

Using desktop linux phones and trying to force that as a norm would set privacy and security back substantially.

The inverse of what you suggest, which is Android with desktop linux app compatibility, would be a huge step forward, and is already much closer than you might think.

Modern phones have substantially better VM support in the hardware than in previous models, and it is maturing at a very fast rate. We would be able to run linux VMs on Android, paired with desktop mode, with evidence for USB passthrough for an externel GPU in AOSP

There is also evidence that we will be able to put desktop linux app icons on the Android homescreen and using them in an app-like fashion.

This would use the more secure host to run the VM for the less secure OS.

But as a Plan B, why aren’t we emulating Android on these devices (or is it the Secure Enclave that’s the spicy bit that these apps need)?

Google needs to experience real competitive pressure, and you need preinstalls for that.

Same story for year of the Linux desktop. It's doomed to 5% or less of market share without preinstalls (which Valve & the various other PCs now releasing with SteamOS are changing)

But also, prohibiting OEMs from making or partnering with "non Google approved" OSes is ridiculous and I'm surprised that hasn't been challenged in court yet as an abuse of monopoly power.

It's definitely planned for GrapheneOS to be sold preinstalled on devices, but it will also be possible to buy devices without it and install it yourself with our web installer. The details need to be worked out. The focus is currently meeting the requirements and porting GrapheneOS to the devices.

Most of what we've landed upstream has been post-Copperhead. AOSP made it increasingly difficult to contribute without being an Android partner and it's nearly impossible now. We've contributed elsewhere including to the Linux kernel and PowerDNS. We don't try to submit security improvements to the Linux kernel anymore based on direct experience of it not being worth the effort required but we still submit patches for bugs. We're not interested in arguing with upstream developers about whether security improvements are worthwhile so we won't contribute those changes to projects not enthusiastic about it. We've made recent contributions to various projects we use including PowerDNS because they don't make it too difficult to contribute.

> What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.

Google didn't invent MTE or memory tagging.

Pixel 8 launched in October 2023 as the first production device with MTE and GrapheneOS began using MTE in production later that month. Pixel OS still doesn't use MTE by default and only began offering a way to use it with Android 16 via Android Advanced Protection Mode (AAPM). AAPM only uses MTE for a few core processes and apps explicitly opting into it which are nearly non-existent. It doesn't use it for the kernel, most of the OS or almost any user installed apps.

GrapheneOS uses MTE for the kernel, all of the base OS processes including apps with a tiny list of minor exceptions to work around HAL issues and many users installed apps by default. It supports opting into using MTE for all user installed apps by default and then disabling it for the ones not compatible with it which are becoming less common in large part due to GrapheneOS users reporting issues to app developers.

https://www.reuters.com/world/europe/kremlin-demands-explana...

I'm actually curious if there's something I don't know about /e/

I'm confident this is a very common experience worldwide, be it with gov IDs or banks.

It's not perfect, but far from useless. Some use it as a daily driver.

Depending on your country, it can be super doable. There are also lots of indie native apps.

    > We're legally allowed to provide compatibility with Google Play via our sandboxed Google Play compatibility layer.

maybe once that happens grapheneos will finally take anti-fingerprinting seriously.

One of the core tenets of truly free software is that I as user must be able to run, access, edit, and view everything.

I never treat my (Android) phone as secure anyway.

Google has changed the game on something you already own. I'm sure their lawyers have done their homework, but in some jurisdictions this is certainly actionable.

People here are complaining about a separate thing, which is that the process for installing an app outside a blessed way is changing, becoming harder for the first such installation and easier for subsequent installations on new devices.

The correct thing to complain about is requiring developer mode for unverified installs, which doesn't seem necessary, not ADV. If you complain about ADV, of course the legislators are going to ignore you. ADV makes Google builds strictly more open and resolves the complaints of the state.

https://developer.huawei.com/consumer/en/arkts/

And now they are adding yet another one, AOT compiled, Cangjie

https://cangjie-lang.cn/en

Using Android fork has been a transition step.

- they're among the most expensive (I could afford that if needed though)

- they don't allow hardware unlock (ehh.. what's the point, then, if I get a locked-down device with Chinese surprises!)

Many banks gate features like mobile check deposit behind the native app. The nearest ATM is 20 minutes away from my house, so unfortunately I consider this feature essential.

To be clear, enough does not mean that will stop every trojan/scam. People send Starbucks gift cards to callers claiming to be from the IRS calling to collect overdue taxes despite the obvious absurdity. Enough means that someone who doesn't know anything about computers but who reads and believes the warning label has sufficient information to know that it's a potentially dangerous decision. Some people will make the dangerous decision anyway, but it's on them at that point.

You can't possibly convince me that Google couldn't develop something like that if they wanted to.

You could probably restrict "risky" APIs like draw-over-other-apps, but tbh I think that would be a worse solution than just making people wait 24 hours once.

We can't keep catering to the lowest common denominator of user. We have lost many computing freedoms over the decades as a result of this. Sorry, but its unacceptable.

If they really want such locked down experience to be the default, they could also just as easily put out a ROM everyone else can flash that has no restrictions. You still get to cater to the lowest common denominator but without taking freedoms away from anyone else that wants to keep them, with official support. No scammer is going to convince someone to plug their phone into their laptop and flash a new ROM in order to scam them. If they can, there's no protections that would have helped in the first place.

one thing that helps me is using OLauncher as replacement from the system "shell" UI. it's on f-droid.

and the News Feed Eradicator browser extension. God's send.

and of course don't install Insta, X, Reddit, etc.

Even worse, last time I checked the source code, it downloads Google's proprietary, obfuscated DroidGuard blobs (which they can change between requests) and execute it in the privileged microG process if an app does a Play Integrity request.

Also note that Motorola Mobility has stepped up to provide the needed hardware security features. So it will expand to a subset of Motorola devices next year.

So no, they are not "only met on a single line of devices", in fact Samsung gets super close, but they remove yellowboot support and cripple the device if you unlock the bootloader.

Google could only grow like it did, because they did things differently.

Other tech giants pay fines for other crimes. For example Facebook once had to pay a record high 5 billion for violating consumers' privacy. It is not surprising, that different companies with different products pay fines for different things.

Not impossible though, my bank and govt eID app did do safetynet, but after enough users complained in both apps you can now skip a warning and use it without issues

Because they will pull the rug here one day too. Why on earth should we trust them to keep this approach to their hardware?

Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.

GrapheneOS does provide a toggle to block apps using the Play Integrity API because we found a small subset of apps using it are not yet enforcing providing a result due to being in the process of phasing it in. This doesn't apply to DRM or direct use of hardware attestation. We have a planned feature for blocking access to DRM as an attack surface reduction feature since it can eliminate a little bit of OS attack surface and a significant part of the TrustZone attack surface. Hardware key attestation has almost no attack surface and doesn't provide any info not available other ways.

> this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.

That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue. That's why they made a point of how they separated the systems for it, but you don't have to trust that on GrapheneOS. If you use a VPN it's irrelevant.

> the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.

That's not an accurate description. It's also implemented via our server by default too. If you use a VPN that's not relevant.

The MediaDRM ID is also widely misunderstood since it is scoped per-app rather than being global. The best way to address it is our planned DRM toggle.

> if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos

We disabled DRM provisioning and usage by default in Vanadium years ago and have a publicly visible feature planned for providing a toggle for native apps being able to use it. We don't have unlimited resources to get everything we want quickly implemented.

> how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?

You're making attestation and DRM key provisioning sound far worse than it is. It's not fingerprinting and it doesn't give them another way to track users in practice. If services want to share data with Google then they don't need any of this to do it and it doesn't inherently result in anything being shared with them that's in any way useful. We have a planned feature for providing a DRM toggle but it's nearly entirely wanted for security, not privacy, and there are bigger security features to implement. There are many planned privacy features which would make a major impact rather than near zero as this would.

Preventing fingerprinting by websites is a very hard problem especially considering things like using timing and performance measurements for it. That's going to be a priority for us. Doing it for native apps would require a massive amount of changes to get anywhere close to websites. We could add 100 features reducing fingerprinting for native apps without accomplishing anything significant. We're focused on privacy features with a larger impact.

With a proper security model and verified boot, you can be certain you, the user, are running exactly the OS you expect to run. You can also properly revoke permissions to software and gate access as you see fit. With root, you cannot guarantee you are running what you expect and apps have to exploit much less to get root access, or just keep root access if given by the user. You cannot revoke godhood, it can just lie and say you revoked it. There is nothing enforcing any security features.

Security isn't binary. Putting up barriers makes it harder for scammers to steal money. There's a reason why they exploit malware to steal money, rather than asking their victims to send them crypto directly.

But no one said we have to copy that flawed concept. macOS and Linux already have a good solution, requiring your full unlock password in a privileged dialog to authorize changes.

It's ridiculous that changing the settings on my device is protected 10× more than transferring all my money to a random person.

We don't go around telling people that it's OK to still run Windows XP for the same reason. Why is/should mobile be any different?

Stop being OK with manufacturers having garbage support. It's completely unacceptable.

Most local privilege escalation (LPE) attacks used to escape the app sandbox, browser renderer sandbox or other sandboxes are done with kernel exploits. There are plenty of LPE vulnerabilities in AOSP userspace code but plenty in the userspace driver and HAL code too. It's definitely the kernel ones which are used most in practice. There are an endless stream of serious Linux kernel vulnerabilities and regularly patching the kernel is crucial to privacy/security.

Nearly all data extraction attacks are currently done with Linux kernel USB exploits and will likely need to switch to Linux kernel radio and other driver exploits when the USB attack vector is unavailable. If you care about privacy then you probably care about protecting your data from someone who obtains your device. That heavily depends on both hardware-based security features and security updates for the firmware, kernel, drivers and HALs in addition to the AOSP portion of userspace.

Disk encryption doesn't truly work on most Android devices for the majority of users because they're missing Weaver throttling support in hardware so a random 6 digit PIN can be easily brute forced once an attacker gets control over the OS. Most users don't use a strong passphrase so Weaver is critical for them. A software rate limiting implementation doesn't hold up to serious attacks.

> A good OS that allows you to remove permissions from apps and further isolate things does a lot for privacy.

Privacy depends on patching privacy vulnerabilities and shipping the standard current generation privacy protections. Android 17 without our improvements has a decent permission model and app sandbox. That's not the case if there are a bunch of privacy holes in the kernel, missing privacy features due to an outdated kernel and privacy holes in the drivers/firmware too such as tracking via Wi-Fi identifiers other than the randomized MAC.

Privacy also heavily depends on security. That's why GrapheneOS puts so much work into security rather than only privacy features. Having a nice privacy model doesn't do any good if adversaries can exploit the OS remotely, from a malicious/compromised app or another way. It doesn't provide any protection for users against many widespread attacks. Play Store regularly catches and bans a lot of apps which use LPE vulnerabilities to take over people's devices. Far more happens via distribution methods without app store review or scanning systems.

We heavily improve privacy with features like Contact Scopes, Storage Scopes, Sensors toggle, Network toggle and other changes. These improvements aren't anywhere close to the highest priority on a device missing crucial privacy and security patches. It's better for someone to have a stock Android device with decent updates than a partial port of GrapheneOS with many of the privacy and security features miss

> I respect your desire to refuse supporting anything but pixels, but please don't pretend that alternate OS on old devices don't improve privacy and security.

Using those devices with LineageOS has nowhere close to reasonable privacy or security. You're missing years of Linux kernel patches, not only patches for the drivers, firmware and HALs. Not patching Linux for years is definitely important and it's not hard to exploit it if it's not getting basic updates, especially without having a lot of kernel hardening. Linux kernel exploit protections are far weaker than Android userspace exploit protections. It's the softer target and has far more privileges so that's what gets targeted. It has massive attack surface for apps despite the massive attack surface reduction done by Android. Android's standard exploit protections including attack surface reduction for the kernel are drastically better in the latest stable releases. It's not only the privacy/security patches which are important but also the standard privacy and security improvements.

The purpose of GrapheneOS is not making a highly insecure device somewhat less insecure while also making it less secure in other ways by losing verified boot and other security features.

GrapheneOS certainly doesn't refuse to support anything other than Pixels. We have an official OEM partnership with Motorola Mobility. We're working with Motorola on multiple devices meeting our requirements and providing official GrapheneOS support which should be available in under a year. You're claiming we aren't doing one of the major things we're actively working on and have announced with Motorola. We're also open to working with other OEMs once we have more resources available. It's not an exclusive partnership, but we're very busy and don't want to spread ourselves too thin.

So far, no other OEM has been both willing and able to make devices meeting our requirements so far. Samsung could do it but currently doesn't allow another OS to make use of many important security features right now since. Samsung permanently cripple devices if they're unlocked and locking it again with the stock OS doesn't restore all the functionality including security features, but even more security features are missing for an alternate OS than what's permanently disabled. They also make it extremely difficult to properly support their devices. They're welcome to change all of this and we could support their devices in the future.

As the userspace improves, more attacks will be (and are) directed at the kernel, the linux kernel is already really bad for security, and it is absolutely vital to keep updating due to its architectural deficiencies and constant issues.

Alternative OSs on subpar hardware do not improve privacy or security. They do the opposite. Other hardware does not provide vital hardware security features, and many OEMs do not provide yellowboot or any proper way to relock the bootloader with another OS. Verified boot is very important for security.

Note that the OEM provides firmware images, an end of life device can never be secure because it lacks critical firmware updates.

This isnt subjective, this isnt rigid, and this isnt a matter of attitude. This is fact.

> 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 ever need to overrule a restriction an app has set, I must have already granted myself the power to do so ahead of time.

Which means there are only two viable paths forward:

1. If I assume that software is perfect, and I will never need to overrule a restriction software sets, I can use stock Android or Graphene OS

2. If I assume that at some point in the future I might someday need to overrule any restriction, I must grant myself root permissions from the start.

Also, I don't need to grant root permissions to random apps.

All that's needed is for the adb and the native file manager to be able to enter sudo mode and read any file, so that in worst case I can always pull all data off the device, and flash a version of the OS with my changes instead.

If we want to go one step further, and want to apply the practical definition of the FSF rights of free software, you should also be able to replace any file using the builtin file manager in sudo mode.

Its not advisable to run anything as root, at all. Or expose access to it in any form.

You can make userdebug builds to access a form of root that doesnt undermine the entire security model, in ADB. Afaik this lets you access apps internal directories but is not recommended for production devices.

An app developer getting access to send my files to a random server somewhere? That's just a simple permission prompt, no unlock needed.

But me getting access to my own files? That's an absolute no-go. Even with adb and unlock, absolutely impossible

Seriously, you need to explain the difference. Because I don't see how apps being a one-way street (they can access my data, but I can't access theirs) is in any way reasonable.