It 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 most stable/bug-free in this list.
- Ubuntu Touch: fully open source and community driven, it uses snap packages for security, you might be able to run android apps. Last time I run it also seemed fairly stable/bug-free.
- PureOS: fully open source and privacy focused. I think it's the only one that, released with the Librem 5, can avoid using proprietary blobs for interfacing with the hardware. Seems less stable than SailfishOS and Ubuntu Touch. You would need to buy a fairly expensive-but-old phone(librem 5) to run it.
- PostmarketOS: fully open source, focused on being lightweight and revive old phones, has a huge amount of phones it has been tested on, is based on Alpine.
- Mobian: mobile version of Debian, it's fairly new on this list.
There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.
These operating systems aren't compatible with most of the apps and services people want to use. It's going to become much worse. The compatibility layers several provide have extremely poor compatibility combined with disabling the Android security model and app sandbox. Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more.
Aside from that, many people care about privacy and security. Each of those operating systems is far less private and drastically less secure than the Android Open Source Project. None has a truly complete and working app sandbox or permission model. None uses modern exploit protections. None has serious hardware-based encryption features needed to protect against data extraction. They're not serious alternatives to an iPhone from a privacy and security perspective as an AOSP-based OS on decent hardware can be.
> but in case we don't manage to push back on this
It's a warning that's being added to Google Mobile Services operating systems. It doesn't negatively impact other operating systems based on the Android Open Source Project.
> various actual linux OSes for mobile
Linux doesn't mean GNU/Linux or systemd/Linux. It doesn't at all imply using glibc, systemd, GNU coreutils, Bash, GNOME, etc. Distributions using different userspace components including several of the ones you've listed are still Linux Android-based operating systems including AOSP and GrapheneOS are Linux distributions. Alpine doesn't use glibc and SailfishOS has a lot of their own mix of open and closed source software. Using a typical desktop Linux userspace stack isn't what makes it Linux and there's also not a lot of consistency in what's used on desktops regardless. A Linux distribution not using musl, glibc, GNU coreutils, etc. is still Linux.
> There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.
AOSP-based mobile operating systems are Linux distributions.
> These operating systems aren't compatible with most of the apps and services people want to use.
Exactly this.
If I can't run WeChat, Venmo, my brokerage app, WhatsApp, etc. it's a non-starter for me. I might as well not have a phone, because these apps are pretty much the only reason I carry around a phone.
"Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more."
Being isolated a little bit more from the kernal offers an illusion of privacy meanwhile where you are, what you have installed, your photos and friends are available to other apps at a much higher level. I understand being able to slow down a nation state actor is important but most privacy concerns for average people happen at the OS level not the kernel.
This claim is false. Isolation and protection from the kernel is vital and it is already targeted for exploitation, and will be targeted even more as time goes on. Properly updating the kernel and improving its isolation and security is the bare minimum for even below average users, not just for high threat models. The claims you are making are unsubstantiated.
I'm using a Librem 5 as my daily phone. PureOS is actively developed and based on Debian. Monthly development updates are published here: https://puri.sm/posts/tag/advanced-readers/
Personally, I do not use Android apps on the Librem 5, but Waydroid is available in the PureOS repository. Waydroid is a container-based approach to boot a full Android system on regular GNU/Linux systems running Wayland based desktop environments (like PureOS).
PureOS also provides convergence via Phosh. Convergence means here that the same app can be used on a phone and on a big screen, the GUI adjusts to the available screen size.
Phosh aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux. Phosh was originally initiated by developers from Purism for the Librem 5 phone but is nowadays used on many different devices covering smartphones, tablets and convertibles. It has even been seen on laptops.
> Waydroid is a container-based approach to boot a full Android system on regular GNU/Linux systems running Wayland based desktop environments (like PureOS).
No, it's only a partially working form of Android with the privacy/security model largely disabled and poor app compatibility. Waydroid is based on an ancient release of Android and disables the SELinux-based privacy/security model. It doesn't contain apps from each other and has far less protection for the Linux kernel from the apps. It has poor app compatibility and isn't a good approach to running Android in another OS. ChromeOS made a proper better Android container not losing the privacy/security model but migrated to using hardware accelerated virtual machines. It makes a lot more sense to use a VM since current era smartphone hardware fully supports it.
> PureOS also provides convergence via Phosh. Convergence means here that the same app can be used on a phone and on a big screen, the GUI adjusts to the available screen size.
Android Open Source Project has a desktop mode. It has a hardware-based virtualization layer for running desktop Linux applications too including GPU acceleration support.
> Phosh aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux.
Android runs fine on mainline Linux. It doesn't require special kernels. That's tied to specific hardware rather than Android.
PureOS has far worse privacy and drastically worse security compared to iOS or AOSP. It's bringing the traditional atrocious privacy and security of desktops to mobile. Librem 5 also combines that with extraordinarily insecure hardware missing basic firmware updates and security protections. As a whole, these make it drastically easier to exploit devices. That includes going back to disk encryption which doesn't work for the average user due to them not using a strong passphrase and not protecting against data extraction with physical access unless the device is turned off.
The way out is for people to support the various Linux phones. These Linux distros need to support and push Android compatibility, so that people can load F-Droid, Aurora, and Obtainium on them and get most of the Android apps they want. The ability to use both Linux and Android apps should satisfy nearly everyone. A strong message of consumer defiance needs to be sent.
The Android family of operating systems and the forks made from the android open source project are all linux distributions, and linux phones.
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.
The problem is that the usage of Android should not be at the expense of users and developers rights to choose, freedom, or privacy. With that line crossed, Android becomes an unattractive option.
With an increase in mobile Linux (e.g. Mobian and others), they can and will get better. Customers and developers choice and freedom are being nullified, because there are few other options. That has to change.
Android is not at the expense of either freedom or privacy. Desktop Linux OSs come at the cost of both. It would be better to direct effort to AOSP projects as it is a much better base to build from.
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.
> Usability-wise, they are no match for Android and iOS—or even versions of them from five years ago.
They're also no match for the privacy or security of iOS or AOSP. They're bringing the lack of privacy/security model and protections on desktop operating systems and hardware to mobile. It's a massive regression for privacy and security despite being marketed in the opposite way.
Biggest problem is banking, rideshare, airlines, various other service provider apps- for example, if a cell phone service requires a particular app, etc. It's not as much of a problem in the United States (besides banking), but I've noticed that in Singapore, for example, all sorts of things are tied to mobile apps.
> Red Hat's UX designers heavily contributed to GNOME
Well, IMHO Gnome has worse UX than other linux environments like KDE, Niri witn Dank Materials Shell, etc. That is obviously a matter of opinion, but I don't think you necessarily need a large budget to get decent UX for an open source project.
I agree that the usability is behind, as we would expect. For me mainly is about missing apps and some hardware support. But in terms of UX for example I liked using SailfishOS, although I'll admit the UI needs some getting used to.
But I prefer this to the feeling that I'm being limited on what I can do on Android/Apple, and the worry of being in a duopoly that allows the companies to worsen their products without ever fearing competition(as far as they do it in small chunks).
Aren't you much more limited by not having access to the vast majority of apps built for Android and iOS? The limitations imposed by Apple and Google have led to thriving software systems. Being free to hack as you want on the system won't help most people if they don't have access to the software people want.
Usability-wise it's hard to make too general statements - for me the killer app on mobile is the ability to independently adjust app volumes which is unavailable on mainline Android/iOS (it is supported by a few vendor branches like Samsung's, though)
FWIW, I use my smartphone as an MP3 player, SMS messenger and TOTP auth. iOS and Android did that fine 5 years ago, I don't need Instagram or 8 Ball Pool to survive in life.
Not useless. It is like the missing printer driver for Linux Desktop. It makes the experience ugly, but this is not the fault of the Linux OSes.
Also the bank should not require apps (instead they can offer hardware key support or desktop apps) and in fact some - at least in Germany - offer a different authentication possibility. Also the app for the German ID is published on fdroid and does not rely on Google services.
Good for Germans then. Slovenian banks won't let you use physical 2FA authenticators (for personal accounts and maybe even business ones at this point) anymore and will also require you to constantly update their stupid app (I've had to replace some otherwise good phones because the OS version wasn't supported anymore).
Probably not the case for most people. I'm living abroad and had to do something on the Brazilian e-gov platform. To log in I had to confirm my ID with an Android app. Not only is it exclusively on Play store, but it also refuses to install on any rooted device, so I had to boot an old non-rooted Android I had stored somewhere.
I'm confident this is a very common experience worldwide, be it with gov IDs or banks.
The question of how useful or not it is is orthogonal to whether it is the "fault" of Linux. Users who can't use it because something they need just doesn't work won't change their minds because the blame lies elsewhere.
There are plenty of banks in Germany which offer over-the-counter services, if you prefer to do banking as if it's 1999. Most of the time, when people say it's impossible to live without a smartphone, it's actually only impossible to enjoy the conveniences of the internet without a smartphone (at least in Germany). Besides these rentable scooters, I can't think of anything that actually requires a smartphone. Sure, you'll miss out on a lot of conveniences, but I remember a time where that was the norm, so it's not like it's unreasonable.
I recently bought my first smartphone, just went for a refurbished Pixel 8 with GrapeheneOS.
To be honest, life without a smartphone was increasingly becoming a PITA.
For example, Ryanair doesn't accept printed tickets anymore.
A few clubs in Berlin (Tresor, Ohm, Oxi) have recently replaced their cloakroom by automated lockers that require a smartphone to operate.
I've encountered a few gyms (2 in Spain, 1 in USA) that use live-updated QR codes to enter the gym.
I did a project in the US and the client's office required a smartphone to open the door.
In Spain it's common since the pandemic to have restaurants that only offer the menu as QR code.
In fact, the pandemic was rough, as you had this system where you had to register with a QR code in most places. In many places they had a paper-registry that I could use, but often I would have to end up just using a friend's phone.
Plus all 4G dumbphones are crap compared to older 2G models. The few that exist are built really bad, designed for old people, lack features like T9. 2G is out already in great parts of the world.
To be honest, it saddens me deeply that the only way to live in society today involves carrying an internet-connected computer in your pocket. But it was just too much of burden... With GrapeheneOS the experience still feels somewhat acceptable and I get a somewhat similar feeling of control to what I get using NixOS on my laptop. But still...
To add to the sibling comment, you are also ignoring the fact that in 1999 nobody had those conveniences, everybody was on equal ground. In 2026, if you handicap yourself by rejecting those "conveniences", you will be met by friction at every step - lower productivity at work, impatient looks from your family members etc.
The comparison to 1999 is not entirely accurate. It doesn't take into account that most physical banking locations closed down. At least here in Belgium for example, you have to go far to find one, and it's often on appointment only.
No, a phone that cannot run the apps that are required for me to attend certain events is in fact useless to me. It's not the fault of Linux mobile vendors that their product is useless to me, but that doesn't change the fact that it is indeed useless
We're moving to a world where it makes sense to have one cheap locked down phone with the society mandated garbage apps on it, and another device that you use for real computing.
Android is going to bifurcate between "phones that run proprietary apps from the play store" and "phones that run software from anywhere else." And while maybe you can get by without banking apps, your life is going to get increasingly harder when you want to do many other things.
Ride hail app? Transit fare app? Government ID app? Airline app? Maybe you don't need them yet, but the best way to model this future is to consider what you'd do if you didn't have a phone at all, and the amount of friction this will generate as the expectations are only entrenched and expanded.
I'm glad people are saying no. It's good to do it as long as we can. But the final outcome seems inevitable now and to me it feels very close.
We aren't given the choice, in many cases. For example I remember a poster here who was forced to have an Android or Apple phone because his kids' school required an app to pick up the kids after school. So his options were to get a big tech phone, or get in trouble for not picking up his kids. "Get the school to come to their senses" was, unfortunately, not an option available to him.
I've been using several GNU/Linux smartphones as my only phones for the past 18 years (with a short exception around 10 years ago when I carried an Android phone too as there was a gap on the market) so I can say from first-hand experience that it's really not such a big deal as everyone keeps painting it. For these kinds of odd needs where you have no hope to fight back you just launch Waydroid, use the app and stop the container afterwards. However, when you do fight back it often turns out that this "mandatory app" isn't actually so mandatory and in turn you contribute to making the world around you a bit better.
Fortunately Google thought about this, so government ID and banking apps usually check that they are running on a sufficiently locked down and officially blessed phone through the Play Integrity API.
I'm living in Poland and the only thing my bank's application gives me that its website doesn't are mobile TOTP-based payments - and even then it just works in Waydroid, so I can still use it on a GNU/Linux phone if I want to.
In my country, partially due to sanctions, you can access the bank via browser and receive 2FA codes on $15 dumb phone. Also why do you need bank app on your phone? Do you like to give money to random strangers on the street? Only scammers need money urgently. Also it is not secure to use the phone as a single factor to access the bank.
I do not have any bank apps on my phone (it is not even connected to the Internet) and I have no problem.
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.
How often are you still receiving physical cheques that mobile deposit is an essential feature? I could probably count on one hand the number of cheques I've deposited or written in the past ~15 years, nor can I say I've been so desperate to access said money that I feel the need to deposit the cheque within moments of receiving it.
My health insurance company sends reimbursement as paper cheques in the mail, so I get multiple cheques per year. Some landlords still aren't recieving rent any other way than by cash or cheque. Happy for your chequeless existence tho!
At least 3 times a month. I have a rental property and my tenant prefers to mail a check instead of paying extra to pay electronically. My spouse gets paid by check for dumb reasons I won't get into. I sometimes get dividends from my insurance company via check. And then several family members still prefer to use checks to pay each other back instead of Venmo or other electronic services.
I blame it on the fact that the US doesn't have a free electronic bank transfer system like the rest of the developed world.
Interesting, I never saw a bank check. The companies typically transfer money directly into the account, and there are P2P transfers by a phone number working between any major banks. So I guess.. I do not need this feature.
Two cases when I've received a bank check without being able to choose an alternative: 1) as payment of proceeds in a class-action lawsuit; 2) when I got a refund from my insurance provider after changing the terms.
These might not be very common, but they're still not really rare in society either.
Carry a second cheap smartphone, like Pixel -a series or iPhone -SE. That one should be used for banking, government apps, for border inspections, etc.
On your main GrapheneOS phone your financial app should be a Bitcoin wallet. The main phone should be off or in the BFU state when you are in a vulnerable situation.
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.
So, you live in a part of the world that still accepts cash. Good for you.
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.
I could do it all in a web browser on a laptop at home as well. Without annoying ads in notifications and without a risk to lose money if the phone gets backdoored.
Online banking is a thing. A heck of a lot more secure than an app on a certified android device passing play integrity but having last received security updates years ago and with a ton of privilege escalation exploits.
Gov id? Just say no.
Might be worth trying to get your gov to pin down the number of users or process to get gov id supported on any new platform.
They likely wont specify 100k people or 10% of population or whatever email/petition but it at least records the requirement that other OSes exist and requires a process to support
I mean gov id app really doesn't matter (for now) you can just use you id card which is credit card sized. (For now has things might change wrt. age verification.)
But banking apps are a problem.
It's not even about the main online banking (you can use a web portal) or storing a EC digitally in you phone (convenient but really unneeded).
The problem is dump, misguided 2FA apps. E.g. credit card 2FA which already mostly required Android/iOS to work or even online banking login 2FA, transaction 2FA etc. with same requirement.
Currently for the later I can still use other methods but for a huge amount of Banks where I live you can't use a credit card (reliably) without Android or iOS as "carrier" for an 2FA app.
This bogus "justification" for not considering any alternative, non-corporate mobile OS on any phone makes no sense
HN commenters will not let it go
Most HN readers have multiple computers, including multiple phones
There is no requirement that one has to run a closed-source banking or government ID app on the same phone as open-source apps, e.g., apps from F-Droid
And it ignores countless people who do not and will never use banking or government ID apps
I tested a banking app for depositing a paper cheque and it was incredibly convenient. At the same time, the app tried to make a plain, unencrypted HTTP connection to www.google.com
I blocked these connection attempts and the app still worked, with plenty of phoney error warnings. I would not be comfortable leaving one of these apps installed on a phone that's charged, powered on and has a cinnection to the internet
Every user is different but it makes no sense to argue on HN of all places that these closed-source banking apps are essential for everyone. Many HN users are never going to use these apps, and rightfully so
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 and AOSP security but it's an entirely different environment on a server. Running a few server applications in weak sandboxes is far different than using a bunch of apps including an enormously complex web browser with a GPU, cellular, Wi-Fi, Bluetooth, NFC, etc. There's also no serious attempt by almost anyone to defend Linux servers and desktops against physical attacks with the disk encryption only even attempting to provide protection for data before the encryption passphrase is entered, not after.
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.
System administrators of a traditional Linux distribution assemble their own OS out of their package and configuration choices. There isn't a well defined standard base OS. That's part of what makes it the traditional approach and is inherently incompatible with the privacy and security approach of AOSP or iOS in many ways.
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.
Linux security is quite bad. Android tries to improve this and GrapheneOS improves it even farther than that.
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.
I really wish SailfishOS supported more hardware. I love sony phones, but the sony phone I love the most isn't supported despite being nearly identical to a supported one
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.
They have 33 supported devices, some are being shipped directly with the OS or have an official agreement with the phone maker, while others are community ports. Even if community ports, they all seem to have high hardware support, and is all very clearly documented.
They focus just on the Librem 5, and not everything is fully working but as I said they prioritised privacy and FOSS. The phone is old but the OS is still in active development.
They focus on supporting as many devices as possible, currently they don't have "main" devices they support, but they plan to. They too have a very clear documentation on features available for each device.
They target devices made with the intent of running linux, but also have a few ports to android devices.
---
You'll notice that there are a few devices that are more "linux-friendly" and that are supported by many of these OSes. Phones from Pinephone and Fairphone being the main ones.
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.
I think this is all a bit optimistic. E.g. when I last looked a the Sony phones supported by SailfishOS, there was only one old model that had reasonable support. Newer phones would boot, but missed support for many hardware features.
E.g., on the XPERIA 10 IV, the camera and mic doesn't work, which makes it hard to use as a phone:
So, I upvoted you, but I have to say that most of these seem to target old devices, released 6 or 8 years ago or more, which have long stopped being sold (and may not even be easy to get second-hand).
Yes most of the devices are old, but I think there are some main ones still being sold.
I bought a Librem 5 a few months ago, so I'm sure on that one.
The Fairphone 5 is around 3 years old, it doesn't seem to be listed in the official store, but they are big on reusing so I think there should be at least a few second-hand ones being sold(I found some on ebay, and some on their forum). I can also see it listed for sale on amazon uk.
The pinephone is another one very old, they seem to have the "basic edition" still avaliable, but it might be slow.
I also noticed SailfishOS is taking pre-orders for a new phone that will be released in october.
But I must admit a lot of the ones I listed might be too expensive if we consider how old they are
Someone needs to create a Linux based mobile OS foundation - Google's domination is contrary to many large companies interests, and if Meta and many other such companies were approached, they may well donate large sums of money in their own strategic interests.
GrapheneOS is currently the blessed child. Like CyanogenMod previously. They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google.
Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
An old article [1] but:
> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
Your claims about this don't make sense. Google does not provide compatibility with GrapheneOS for Google Play services. They do not provide support for using it or fix the issues introduced in new releases.
GrapheneOS doesn't license Google Mobile Services (GMS), doesn't include it in the OS and doesn't have Google certification. It isn't permitted by the Google Play Integrity API device and strong integrity levels because it doesn't have a GMS license. Google doesn't offer any way for GrapheneOS to license it.
We're legally allowed to provide compatibility with Google Play via our sandboxed Google Play compatibility layer. Similar to APK mirror sites, we're also allowed to mirror the freely available APKs.
We've put enormous time into developing sandboxed Google Play compatibility layer and there's ongoing work to continue resolving edge cases we haven't covered. If Google wanted Google Play to be used outside of stock operating systems licensing it, they could make it work as a set of regular sandboxed apps without us needing a compatibility layer. Our baseline compatibility layer isn't doing anything they couldn't do themselves by making them apps handle being portable to operating systems not deeply integrating it into the OS with highly privileged access.
> and they are legally allowed to fingerprint grapheneos and block Play functionality.
No, and you also don't understand how the Play Integrity API is implemented.
Google has a bunch of monopolies tied to Android. Antitrust laws put limits on what they're allowed to do which Google has been egregiously violating for many years.
Google isn't legally allowed to pull a bait and switch with Android by changing it away from an open platform and open source project. They used Android being both of those things to build and expand monopolies in a bunch of areas. The way Google exerts control over OEM partners with Google Mobile Services licensing has already been found to be illegal in multiple countries and they're in the process of losing more court cases over it. South Korea found their terms to be highly illegal and Samsung is already largely free from their restrictions.
Play Integrity API enforces the Google Mobile Services licensing model. The licensing model and terms are highly illegal in countries with decent antitrust law. It has already been found to be illegal by the courts in multiple countries. EU and US have particularly strong laws where they're egregiously violating and that's going to have consequences.
Play Integrity API is primarily based on hardware attestation, which is not fingerprinting. The strong integrity level fully requires hardware attestation and services using it are migrating to enforcing that. Device integrity level requires hardware attestation for devices known to have a working implementation which is a major loophole but it's gradually being closed. Play Integrity API also has many software checks.
Play Integrity API software checks require having an immense amount of privileged access which means it's not very compatible with sandboxed Google Play without an immense amount of work which would achieve nothing. Tricking all the software checks won't make it start permitting GrapheneOS. It's not feasible to pretend the device is one without hardware attestation while avoiding it being detected that it's being faked. None of this can be feasibly bypassed in the long term without it repeatedly breaking and becoming increasingly impractical to bypass. Many apps already require hardware attestation via the strong integrity level and eventually Google will close the loopholes for the device integrity level.
> maybe once that happens grapheneos will finally take anti-fingerprinting seriously
It isn't fingerprinting and no amount of anti-fingerprinting will bypass it. Hardware attestation exists and it provides the device model and OS. It's also easy for apps to detect those in many ways. Apps can just look at their own memory and see the OS libraries loaded into them. The only way to pretend to be the stock OS even without hardware attestation would be making essentially no changes to anything since apps can look at a lot of OS libraries, etc.
Running apps in VM wouldn't solve anything either and will only work for apps which don't try to detect being in a VM and don't use hardware attestation or the Play Integrity API. We'll still need to support running apps on bare metal once we have VM isolation features since one of the main things apps doing these anti-tampering and attestation checks is trying to block is being run in a virtual environment.
giving the option to completely block attestation and DRM API would be a good start.
> hardware attestation, which is not fingerprinting
this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.
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.
if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos. how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
> giving the option to completely block attestation and DRM API would be a good start.
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.
> 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.
which is what the user would want or be fine with in this case... present the option.
> 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.
you appear to not know how it works, which doesn't inspire confidence.
both remote attestation packets and DRM license request responses contain a unique hardware identifier that can be extracted with knowledge of the right secret information.
in the case of attestation, privacy CA and the verifier must collude to do this (technically, you need the ephemeral key provisioning packet + attestation packet + secrets). blind signatures were proposed to make this impossible and REJECTED. using a proxy/VPN does not prevent having your unique hardware identifier be attributed to the attestation in this scenario. also note how when you attest to google both the CA and verifier are one and the same...
with DRM I'm not even aware of any effort to not directly expose the KeyBox public key to a license server, and ANY app can make use of DRM API. you do need the license server's private key to extract the identifier however.
Permit faking hardware attestation by providing a remote attestation provider device that runs stock Android and a corresponding app. When app on GrapheneOS asks to be attested, that request gets routed via the cloud to the stock Android remote device. People will have to buy 2 phones, one running GrapheneOS that they actually use, one that runs stock Android that they can lock up in a closet plugged into power.
>> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
>So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
It's a nice effort, but without preinstalls you aren't going to capture the market except for the tiny percentage of enthusiasts which are maybe a fraction of a percent of the market.
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.
GrapheneOS has an official partnership with Motorola Mobility which is improving their next generation devices to meet our requirements and helping us port GrapheneOS to those. GrapheneOS will be officially supported on those devices with Motorola Mobility providing us with the stripped down hardware support code we need to support their devices with proper firmware/driver/HAL updates.
A bunch of companies are already selling devices with GrapheneOS installed. Those companies can start buying the future Motorola devices supported by GrapheneOS and doing the same thing with those which they already do with Pixels. Motorola can also specifically sell devices to other companies to sell with GrapheneOS with official support from Motorola.
> prohibiting OEMs from making or partnering with "non Google approved" OSes
It has been challenged in court and ruled to be illegal in South Korea and elsewhere. Regardless, it's only an inconvenience and can be worked around. Even if Motorola can't sell devices with GrapheneOS in many countries themselves, those can still be sold by other companies and Motorola can sell devices to those companies at wholesale rates where they can match the price of the non-GrapheneOS devices. Other than Google, most OEMs aren't directly selling most of their devices anyway.
> What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
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.
> They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google.
Very little in GrapheneOS has gone back upstream post-Copperhead.
> Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.
> Very little in GrapheneOS has gone back upstream post-Copperhead.
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.
Doesn't GrapheneOS supports only Google Pixel smartphones now? For most of the users, that would mean changing their phones beforehand. And if we're talking about common people (especially not in US), it's not even everyone who can afford that. Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
The vast majority of smartphones don't allow installing another OS. Multiple Android OEMs have been restricting or fully phasing out supporting it. Among devices which do permit it, none have provided the hardware-based security features or driver/firmware update support needed by GrapheneOS beyond Pixels. Our hardware requirements are listed here:
GrapheneOS has an official OEM partnership with Motorola Mobility and a subset of their next generation devices will be provided official support for GrapheneOS. They'll be providing us with a more minimal form of hardware support code close to the standard Qualcomm and other vendor code, so it will be cleaner than Pixels. Our partnership with Motorola is non-exclusive so we're free to support other devices with the help of other OEMs interested in meeting our requirements, but no other OEM is working with us yet.
We can't use devices with an end-of-life Linux kernel, no firmware updates, no driver/HAL updates and no support for important hardware-based security features we use. Several devices of a lot of the way towards providing what we need and several next generation Motorola devices will provide it. Other OEMs can do the same.
Have you considered being less puritanical about these requirements? Surely there would still be strong benefits for many users on other devices which would only be able to run if these were relaxed.
Our requirements are for industry standard privacy/security patches and protections. We haven't set a high bar but rather have very reasonable requirements. There's nothing puritanical about requiring what we do for a privacy and security project.
Most people don't have a device permitting using another OS at all or without crippling functionality including security. They need to buy a device to use another OS as a production quality daily driver. The vast majority of GrapheneOS users bought devices to use GrapheneOS rather than using GrapheneOS because it was available for a device they bought without considering it.
We don't want people to buy devices which will stop getting privacy/security patches for the firmware, kernel, drivers and HALs after 2-3 years and are missing important security protections. If we support a device then people are going to buy it to use GrapheneOS. Few of the people who end up using it are going to be people who already had it.
We don't want to have a watered down form of GrapheneOS without the core protections including what we build with hardware memory tagging. Older devices which we discourage buying not providing all the current requirements is much different from adding new devices without those. Our recommended devices (Pixel 8 and later) provide all of the current requirements and we strongly discourage buying older devices without enough support time remaining or the current protections.
We have a serious OEM partnership because we stand by our requirements and haven't watered down GrapheneOS. An OEM working with us to improve their devices to meet our requirements and helping port GrapheneOS to those with full functionality is only possible because we don't poorly support anything able to run another OS.
GrapheneOS is open source and others are free to make incomplete ports to other devices under a different name. Many individuals and companies have done this and it hasn't gained any significant interested. It doesn't provide what GrapheneOS does and the expectations of our audience are much higher. Our audience doesn't want a device with 2-3 years of delayed security patches for the firmware, kernel, drivers and HALs follow by end-of-life.
Other projects (like LineageOS or /e/OS) have lower requirements. My experience is that it makes it very hard to know what kind of security you get. I have used /e/OS for a couple years before realising that it was signed with the Google test keys (so not signed) and the bootloader was not locked. And they were not forwarding the manufacturer updates, so Stock Android had the manufacturer updates and on my /e/OS they were 4 years old (!).
If you have GrapheneOS, you have the best mobile security you can get, period.
> Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
I bought an iPhone based on that very decision. TBH, I regret it. The ecosystem is so locked down that I can't even sync my photos to my NAS without a hacky constantly breaking shortcut, building my own app, or paying for an app. Just to replace a small <50 line bash script that could do more than either the shortcut or any paid app I know. I'm constantly battling my phone.
That would all be worth it, but it's been a few years and Google did all the shitty stuff I was protesting anyways and Apple is getting worse.
I'm hoping we get those moto phones with graphene pre installed so I can actually send the right market signal. But what's fucked up these days is you can't send the right market signal. Meanwhile I talk about fixing shit at work and my coworkers ask "what's the value" or say "there probably isn't any money in doing that". Even for problems they are one liner fixes and that they agree we spent more time arguing over than it would be to fix it. I don't think it's a top down problem, it's a bottom up. Those are much harder to solve
> Doesn't GrapheneOS supports only Google Pixel smartphones now?
For good reasons. Most other devices arent secure enough to guarantee privacy. Especially not if loaded with a custom operating system (most devices don't allow to verify the boot chain with a custom OS)
> And if we're talking about common people (especially not in US), it's not even everyone who can afford that.
You can get a new Pixel 9a here in europe for around 350€ and it will be supported at least until April 2032
> Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
Google phones are surprisingly open and work well. Google takes a pro-user stance here that is extremely rare in the ecosystem, so why not support this product?
It's alright, whatever the reasons might be, but let's not pretend there are no other ways out. I'm content with newest LineageOS on my 7 year old mid-range Xiaomi. I don't mind the loss of privacy guarantee. I don't have to spend any extra 350 euros and lose the headphone jack in the process.
An end-of-life Xiaomi device with no privacy or security patches for the firmware, Linux kernel, drivers and HALs for years doesn't provide the bare minimum for protecting user privacy and security.
It would theoretically be possible to port it to a newer kernel but that's not within the scope of LineageOS. It doesn't do that so there aren't Linux kernel updates since the kernel branch has been end-of-life for years already. It would also theoretically be possible to rewrite all the userspace drivers and HALs, but it's not being done. The firmware is a different story since it's usually signed and requires vendor support. It's important too since it's exposed to remote attacks via cellular, Wi-Fi, Bluetooth, NFC, GPU (web browsers, etc.) and more.
> An end-of-life Xiaomi device with no privacy or security patches for the firmware, Linux kernel, drivers and HALs for years doesn't provide the bare minimum for protecting user privacy and security.
Your very rigid view of the world is so distorted to the point of being absurd. You know damn well that the vast, vast majority of spying on Android is done in userspace.
A good OS that allows you to remove permissions from apps and further isolate things does a lot for privacy.
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.
Frankly, that kind of rigid attitude/black and white thinking might be why you find it so hard to collaborate with upstreams.
I don't think its rigid at all. Its important to continue to be able to receive security updates. If a device can't, mostly because qualcomm/firmware no longer wants to bother 6 months after release, it's DoA.
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.
The main issue is that OEMs make too many device models with unnecessary variations for carriers/regions and make too many changes to AOSP. It's extremely hard for them to properly maintain all of it.
Qualcomm offers up to 8 years of updates from platform launch. Getting around 7
years of updates requires OEMs to use the latest and great platform combined with paying Qualcomm a lot of money for long term support. It may cost a million dollars or more for each year of support. OEMs also need similar support for other components but that mostly means choosing decent components.
Providing proper updates has a cost most OEMs haven't been willing to pay. Pixels and Samsung flagships have been the exceptions. Samsung doesn't properly update most devices, only flagships, and it's still worse than Pixels in important ways. Samsung has also been closest to having all the hardware-based security features we need but doesn't let us use a lot of those due to crippling devices if they're ever unlocked.
Our partnership with Motorola Mobility partly involves them improving their devices to meet all of our requirements which was already largely happening. It also requires porting GrapheneOS to their devices and fully supporting Snapdragon again including having hardware memory tagging support on it for the first time. No one is currently using hardware memory tagging in production on Snapdragon let alone for the entire kernel and userspace as we do so it's going to be a lot of work. Motorola is going to be helping with all of this. They're also going to provide us more minimal hardware support code without unnecessary changes not needed for AOSP / GrapheneOS. A bunch of GrapheneOS features need to be ported and the device support code needs to be made compatible with our changes too including but not limited to fixing memory corruption bugs.
GrapheneOS uses all of the standard Android security features including hardware-based security features. It also adds major security improvements including features heavily based on hardware security features which are either entirely unused or barely used by AOSP or the Pixel OS. Heavily using hardware memory tagging, integrating our USB protection with the USB controller and other features are core parts of what makes it GrapheneOS. An incomplete port without all the standard security features or the GrapheneOS added security features isn't GrapheneOS.
GrapheneOS closely follows along with Android releases, Linux kernel LTS revisions and driver/firmware updates. It had an experimental release based an Android 17 after only 2 days of it being released earlier this month. It quickly made it through our testing process with many regressions resolved to our Stable channel. This is part of what makes it GrapheneOS and an incomplete port to another device without the same updates wouldn't be GrapheneOS.
GrapheneOS is open source. People can make an incomplete port of GrapheneOS to other devices using their own project name. It's not a port of GrapheneOS to another device without having all the features and updates.
We phase in new hardware requirements for standard security features and the older generation devices without those are eventually gone. Adding a new device without hardware memory tagging would be far different than still supporting 6th/7th gen Pixels without it since we strongly recommend against buying those devices anymore and they're going to end up end-of-life.
But on a Linux kernel that old userspace is kernelspace. There have been so many privilege escalation exploits in the kernel since then there is no difference. Every app you install effectively runs as kernel or root if it wants to.
> Your very rigid view of the world is so distorted to the point of being absurd. You know damn well that the vast, vast majority of spying on Android is done in userspace.
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.
An objective and accurate assessment of the available options is not absurd, its the bare minimum.
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.
> Google phones are surprisingly open and work well. Google takes a pro-user stance here that is extremely rare in the ecosystem, so why not support this product?
Because they will pull the rug here one day too. Why on earth should we trust them to keep this approach to their hardware?
The vast majority of smartphones don't allow installing another OS. Multiple Android OEMs have been restricting or fully phasing out supporting it. Among devices which do permit it, none have provided the hardware-based security features or driver/firmware update support needed by GrapheneOS beyond Pixels. Our hardware requirements are listed here:
https://grapheneos.org/faq#future-devices
GrapheneOS has an official OEM partnership with Motorola Mobility and a subset of their next generation devices will be provided official support for GrapheneOS. They'll be providing us with a more minimal form of hardware support code close to the standard Qualcomm and other vendor code, so it will be cleaner than Pixels. Our partnership with Motorola is non-exclusive so we're free to support other devices with the help of other OEMs interested in meeting our requirements, but no other OEM is working with us yet.
We can't use devices with an end-of-life Linux kernel, no firmware updates, no driver/HAL updates and no support for important hardware-based security features we use. Several devices of a lot of the way towards providing what we need and several next generation Motorola devices will provide it. Other OEMs can do the same.
To avoid writing the same thing a 2nd time without forcing people to use a link and lose their place where they were reading.
> barely answers the question
We fully answered the question by explaining why we currently have to use Pixels and why we won't depend on Pixels anymore in less than a year. You're ignoring our explanation of our Motorola Mobility partnership. It explains why we need the partnership instead of adding support for devices without it too.
> But you answered with your text about how other smartphones don't have important "hardware-based security features".
No, we explained most devices don't even allow another OS and many of the ones which do cripple functionality including security so we can't support those. We also explained we need firmware, kernel, driver and HAL updates for a reasonable amount of time. We need the hardware-based security features we use to implement the core protections provided against attacks. It wouldn't be GrapheneOS without solid protection against remote attacks, apps and data extraction. We linked to https://grapheneos.org/faq#future-devices which lists out what we need. It's strange to ignore updates or put scare quotes around something we provided a detailed explanation for in the linked content.
You can't trust Google not to pull the rug. That's a big part of the reason GrapheneOS now has a deal with Motorola for the next generation of devices.
they are already pulling the rug. Google took months to publish devicetrees for the Pixel 10. they've signaled (iirc) that they'll no longer make the Pixel line capable of running AOSP. the reason they even did at first was to make Pixel a reference implementation that vendors could use to port Android, but now they've announced a switch to an emulated device for that purpose.
Convincing developers, especially bank and gov apps, is near impossible and won't scale well. Going after Alphabet for not meeting DMA obligations seems the easier path. Might not go anywhere but worth a shot.
1. Provide or find pro bono legal resources deeply familiar with EU DMA and similar antitrust regulations, willing to proof-check and improve this report, and perhaps advise on better channels to submit it.
2. Locate more affected end-users, including applicable members of the GrapheneOS Foundation and developers behind other distributions, make them aware of these efforts so that hopefully we submit a joint complaint. (Might get more traction, though AFAICT reporting is limited to EU citizens).
Happy to fork this into its own repository if it helps with collaboration.
A heads-up: the FSFE has already submitted a case for device neutrality regarding both, the ability to completely uninstall AI features and the unlimited interoperability decoupled from ADV: https://fsfe.org/news/2026/news-20260615-01.en.html
“Interoperability must be decoupled from developer verification procedures. We need clear, precise, and inclusive rules to prevent circumvention by gatekeepers and to ensure that interoperability becomes a concrete reality in practice” states Lucas Lasota, FSFE Legal Programme Manager
> Convincing developers, especially bank and gov apps, is near impossible and won't scale well
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
Graphene OS user here. Almost all of the apps I tried work fine. All the banking apps I use work. Have you tried reaching out to the app developer or the service and explaining what Graphene OS is and asking them to support it? I was able to persuade one app to do it.
Problem is that all banks require a national centrale controlled service for login (BankID in Norway). And it is this service that I cannot get to work running GrapheneOS. It worked a couple of months ago, but not anymore. And all customer services and complaints are directed to your bank who 1) has no idea what i am talking about and 2) no control over BankID verification requirements.
I did actually alert BankID about this potential lock-in issue back when they announced they would be abandoning the SIM-based (and thus phone-independent) solution, to little understanding and just general comments about the cost of keeping the SIM-based solution alive. I guess now with eSIM being prevalent it wouldn't have made much difference anyway.
But just the thought of the potential to be completely locked out of everything from banks to online payments, logins to the public health system, tax filings (and basically all public sector services) just at the whim of Google or Apple's automated algorithms misunderstanding some random account activity, is a thought that should make everyone (and especially those in countries dependent on systems like BankID) afraid and demand at minimum:
Rights to:
- Due Process
- Accountability from Google & Apple and fines for when they do wrong
- Multiple warnings (with a right to know what you're being accused of) before being locked out
- Well-functioning complaint procedures with strict time frames
- Make the mere concept of banning users "for life" illegal
...from Google and Apple (and strict fines for them not adhering to them). Feel free to add more to the list.
Else we as a society can't depend on a smartphone as the main key to our lives anymore.
I’ve nearly decided to switch back to the code brick instead of BankID app. It’s less convenient, but with the way things are going, I’m just not sure I want to exist in the digital world much longer.
I switched to GrapheneOS a couple months ago, and the only real downside is that MitID (danish verison of BankID) doesn't work. I got the code brick and attached it to my keyring and it's honestly not that bad, I usually have the keys close by anyway. Also most apps that need MitID allow you to create a pin to log in without reverification once you've logged in once.
lol, this problem stopped me from installing GrapheneOS early.
But now.. I removed banking apps by myself because my state require room them to collect phone fingerprint and access to location EACH time they opened.
So... looks like now nothing stops me
AOSP is a Linux-based mobile OS. It runs fine on top of standard Linux kernels without downstream changes. Getting rid of the need for closed source userspace drivers for components like a modern Mali GPU can be done with AOSP and will benefit the most people that way. AOSP if many companies and others band together to do it. It could also happen due to government intervention due to Google's antitrust law violations, but that could be done poorly in a way that harms open source.
I keep hoping for something more radical like Jolla and SailfishOS taking off or postmarketOS becoming a true viable alternative but as things are looking like now there's a better chance we'll ditch phones altogether in 10 years when smart glasses will replace them instead.
> we'll ditch phones altogether in 10 years when smart glasses will replace them instead.
Billions are spend right now to make sure the glasses also run Android or iOS. So far, Google, Samsung, Magic Leap, RealWear and Vuzix are working with/on Android XR, and obliviously Apple is working on AR/VR iOS.
Meta and a couple of smaller startups are doing something in-house, but I don't give them much chances to get an ecosystem going.
I know Graphene has innovative security measures, do you happen to know whether that includes anything wrt. phishing or social engineering?
(For those who haven't been following along: this whole affair started with phishing. People were social-engineered into installing an app and a little later their bank accounts were empty. A big issue in various poor countries.)
That's one of its primary arguments: besides the hardening against exploits, they're considered such a safe OS because you cannot access your data either and give the wrong app root access. Everything lives in a sandbox. Whether not being able to grant full access to e.g. adb shell, Termux, or Restic is what you want is a personal choice, but it adds a layer of security against any malware that tries to get you to grant them root access
This is also the argument they use to try to convince app vendors to add their keys to the allowlist, because the app makers can trust that their DRM will be active (if Netflix sets a "no screen recording" flag, you the user cannot circumvent it by e.g. reading /dev/fb0). It should have broader compatibility than other FOSS Android builds (when running the officially signed version of course, you can't compile it yourself and expect such apps to run there)
You are free to make your own build of GrapheneOS with root access and have extremely reduced security. Just don’t expect support on the forums and waste everyone’s time when something happens.
Any security measures taken always remove agency from one person and give it to another.
iOS takes my control away, and in turn gives that control to Apple. GrapheneOS takes my control away and gives that to the GrapheneOS developers.
The "security" you're talking about doesn't prevent certain data from being accessed, it just changes who controls the access.
If the user cannot be trusted with their own data, then there is no solution anyway. They'll just tell their private data to a scammer on the phone instead.
There is no solution against a user that wants to give their own data away, but if you try to prevent that, the only thing you'll accomplish is destroying general purpose computing.
The sad part is that this has a solution. It's called adb root. Your adb stays locked unless you unlock it, and you're not able to get root on the phone. But you can through the adb shell, meaning that when app X wants to screw your data away from you you can still copy it. There is something deeply wrong about locking filesystems even from read access. GrapheneOS should at the very least give a full read-only access to the fs through (possibly) limited adb access.
Root access takes agency away from you and gives it to 3rd party software. It doesnt expand freedom at all, it just allows other software to abuse the user.
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.
I just don't get why we need to argue about something — the right to general purpose computing — which has been answered decades ago?
The user must be the administrator of their own device. Whether that's a laptop, desktop, PDA, mp3-player, smartphone, tablet, cyberdeck, netbook, or any other kind of computing device.
The user must be able to overrule any and all decisions. That's the definition of ownership.
Like, this was the reason why GNU was founded, and before that was the plot of the movie TRON.
Being the administrator and being able to sidestep OS protections are not the same thing. Without root, the user is in control of what application does what and how. With root, the user is not. Root is not freedom or ownership, like many try to claim. Root is a hacky shortcut to proper functionality. 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.
Its really funny because Tron, or at least Tron Legacy, is a great example of why godhood is dangerous and why a user and a program having root access is catastrophic.
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 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.
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.
Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
The randomness of an app is irrelevant and apps need to jump through significantly less loops to obtain root access without your input. And even if they didnt do that, and you permitted root instead, the app can lie about you revoking it later in either case.
This is blind ideology over safety and real ownership. Root is a hacky shortcut for proper functionality, and is not a prerequisite to ownership in the slightest.
> Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
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.
You would install your own build of GrapheneOS. Not the official images.
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.
> You would install your own build of GrapheneOS. Not the official images.
Awesome, so you're advising against installing GrapheneOS for anyone that wants control over their own data.
Sorry for twisting the words slightly, but that's the essence of the issue here, isn't it?
> Its not advisable to run anything as root, at all. Or expose access to it in any form.
And then you advise for exposing access to it in pretty much the same form I asked for before.
It'd be funny if it wasn't so exhausting.
Regarding the security model: So adjust the security model.
Any access that an app can have, should also be available to the user. Importantly, they should be able to access and modify any data.
The system documents/files app already has special permissions for that, there's no reason why it shouldn't have access to all files (accessible through the same unlock system as e.g. the security settings)
No, official GrapheneOS is an ideal method to control data. As a part of this, they also provide build documentation for whatever you want to do. It is FOSS, after all.
To be clear, I am NOT advising root access. I am not contradicting myself. I am telling you it is dangerous but still telling you how it can be done in a less terrible way. To withhold that info would be senseless gatekeeping. GrapheneOS supports being built as a userdebug image but that will not stop them from telling you how bad an idea it is to use it on a production device.
GrapheneOS will not be rolling back aspects of the security model. That would be a massive step backwards for privacy and security.
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.
We're still arguing for several reasons, one of them is that people still confuse the user with the owner, as you do. "The user must be able to override" is implies that if you have physical access to someone's phone, you can install a keylogger before handing the phone back its owner. Nice for you but I imagine the owner might still quibble, even if you quote TRON.
If I hand my windows laptop to someone, they can also install a keylogger.
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.
> 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.
You use operating systems that have significantly worse security than GOS, iOS and even stock Android as your examples?
Also you literally are the owner with GrapheneOS, lacking security is not "full ownership." You can create your own build of GOS, you can modify it ahead of time, you can literally see all of the source code it's running.
Claiming GOS isn't true ownership is like complaining that you can't change your car's wheel alignment while driving it and saying it means you don't truly own your car.
>If the user cannot be trusted with their own data, then there is no solution anyway. They'll just tell their private data to a scammer on the phone instead.
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.
Moreover it seems to be limited to south east asia for now. Just because you're in the US and all the scams you're getting is cold calls from microsoft tech support, doesn't mean scams with smartphone malware doesn't exist.
>You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
>The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
In other words, "if we had world peace and everyone could hold hands and sing kumbaya, then we won't have to worry about scams!"
Is anything bulletproof against the user signing away their data? I think the question was whether it has any measures in this regard, not whether it's impossible to get phished
It's complicated… in a sense the bulletproof solutions are the ones that raise the cost of executing the attack above the average take. In another sense even they aren't bulletproof.
This particular attack requires getting users to sideload apps that would be rejected by the play store, and most users don't have developer mode enabled. Therefore, the cost of persuading someone to enable developer mode matters. If the procedure to enable developer mode changes from "open settings, scroll down, tap, scroll down, tap seven times" to include e.g. a 96-hour wait for developer mode to be enabled, then the cost of the attack rises by whatever it costs to stay in close contact with the victim for 96 hours, close enough to react if the victim comes close to realising the truth.
This isn't a guarantee. You can still get phished even if the phisher has to spend 96 hours in intensive contact with you. Some victims are worth that effort, maybe you are, and maybe the phisher made a mistake and puts in the effort to phish you based on the mistaken assumption that you're a millionaire.
There are also other things like that. If Google can ban the keylogger you use quicker than you can deploy new builds, for example. Still no guarantee.
> do you happen to know whether that includes anything wrt. phishing or social engineering?
Yes. For example if you install an apk from an unknown source (like a random website via browser or messenger) it will warn you what you are about to do and what effects that has.
You don't need to block stupid behavior. Just make sure users are well aware of their actions as long as they actually read warnings.
my brother in Christ, people who root their phones don't fall for "Hello sir, I'm sir John from Microsoft, you have virus sir, please do the needful install antivirus and send gift card sir."
1) Anyone can fall for a scam. Especially those who believe they wouldn't fall for a scam. This is why ridiculing those who fall for [a] scam is harmful, and serves scammers. 2) You can root a smartphone for someone else's usage. For example, I can install pmOS on a smartphone and hand it over to my kid.
You’re right, they just fall for installing updates or CLI tools which install compromised dependencies and run wild on a rooted system before getting caught 24 hours later.
The reality is that these types of problems affect too few people to matter. No appreciable amount of people will switch, or are even capable of it. And even if you made it a no-brainer, most people aren't going to change the OS that came on their device, warranty or not.
AOSP is open source and written by Google. If you strictly don't want Google, you don't use Android. But IMO it's a shame because AOSP is actually good.
You could argue that you don't want to buy a Pixel because that would be giving money to Google, but not giving money to Google does not help the good alternatives, does it? IMO, helping the good alternatives means supporting GrapheneOS. The bigger GrapheneOS gets, the more likely it is that they get to work with major manufacturers (they already work with Motorola, which is great).
If you buy a Fairphone and run LineageOS, you are still running Google code (AOSP) and you support Fairphone who do not seem to care so much about security (otherwise they would meet the requirements of GrapheneOS).
Not only you use Android OS developed by Google, somehow you choose a less open OS distribution, exposing you MORE to Google and their shit, only because you don't want to use their hardware that happens to actually be as open as it gets, including the firmware?
Why do you choose to die on that hill? It's ridiculous!
Is the bootloader locked and signed with reasonable keys? If not, you lose the secure boot, which defeats the point of the Android security model.
Do you get manufacturer updates? My experience with /e/OS was that the Stock Android was up-to-date but /e/OS was 4 years behind, on a Fairphone.
> for reasons I do not understand, Graphene OS is very closely tied with Google hardware
One of the requirements is precisely to be able to add custom keys and relock the bootloader, in order to keep the Android security model. Most other phones don't allow that.
Pixels are consistently "third party Android builds friendly", plus GrapheneOS has a list of required security features (beyond their control): https://grapheneos.org/faq#future-devices
e.g. first one in the list:
> Support for using alternate operating systems including full hardware security functionality
GrapheneOS wants users to lock the bootloader (≈enable Secure Boot) after install by providing user signing keys (avb_custom_key) -- that already seems to leave only Pixel, Nothing and Fairphone.
If they're only supported on a single line of devices made by a single company and there are thousands of devices made by hundreds of companies, then that's not industry standard. It might be better than industry standard, and it might be good, but it's hardly common.
Most of the hardware security requirements are met by multiple lines of devices. The issue is, not all of them are met. Many have poor updates or intentionally cripple standard features for anti competitive reasons.
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.
/e/ OS with Fairphone is the good choice for that. Don't listen to cromka, /e/ OS is now fully open as the only proprietary app was the map one and they just replaced it. So, 100% free software. It is less secure than Graphene but also leaks less data to advertising companies.
> /e/ OS with Fairphone is the good choice for that.
That's debatable. /e/OS is mostly made of AOSP, which is made by Google.
> It is less secure than Graphene
Most definitely, yes
> but also leaks less data to advertising companies.
This is wrong. If you don't use microg on /e/OS or Play Services on GrapheneOS, then it's equivalent. If you use microg, it still contacts the Google servers even though it is an open source reverse-engineered implementation of Play Services. The added privacy there is to go through a proxy, which GrapheneOS offers.
I actually like it better to run sandboxed Play Services through the GrapheneOS proxy, because in my experience it works a lot better than microg.
Really, the only reason to use LineageOS or /e/OS (which are interesting project, really) is that you cannot run GrapheneOS on your phone. If you have the possibility to use GrapheneOS, there is no good reason not to do it.
Your phone is running proprietary Google DroidGuard blobs in a privileged process every time an app initiates a Play Integrity request.
If you install some Google apps like Google Maps, they are run with more privileges than other apps (their microG fork gives apps elevated privileges when they match certain Google signing key fingerprints).
Also, your device is running a firmware bundle provided by Fairphone's Chinese ODM, including TCL image processing blobs. Your phone will soon run an ancient kernel and firmware tree with many known critical CVEs.
But this all doesn't matter anyway, because security hardening is only for spies and pedophiles according to the CEO of Murena (the company that makes /e/OS).
The resason is that only Google bothers to put enough hardware security features to build software on top that allows to make a really secure device that blocks tampering.
Thats are improving peoples security overall by only using pixels at this time. Nothing else currently meets the hardware security requirements except pixel devices. To use subpar hardware would set the security back substantially. They are not going to compromise on security for the sake of broad device support.
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.
Their goal is to hold a standard of security and privacy that can be trusted. They want the brand to be associated with that level of security and privacy. Sticking to Pixel allows them to leave their brand undiluted in this respect.
I wonder if it makes sense to create an independent hard-fork of AOSP in the future. But probably the only option to keep this somehow maintainable is to replace many android-specific components with other userspace linux components that are already well maintained (systemd, networkmanager, wayland)
I understand the frustration (I'm an avid fdroid user across many many devices). But this article comes off as childish with the virus/trojan/"malware vendor".
With such an article, many (including perhaps google) get the ammo to disregard what fdroid says, by branding them as childish/not to be taken seriously. for eg: no reputable news org is going to post this.
I thought the same thing but he apparently has a point. The stated purpose covers only a tiny sliver of the capabilities. The agreement points to the TOS where it (last time I looked) says service may be terminated at any time without stating a reason. Nothing guarantees it won't be used for things other than security. And finally he has a point where it also doesn't really do much for security.
If we ask their fine search engine, the AI helpfully explains malware to be software designed to gain unauthorized access to disrupt, extort payments and/or hijack devices.
If you still think the shoe doesn't fit, imagine what would happen if one managed to create an app with the same capabilities. Google would remove it immediately for being malware. Obvious malware.
but I can totally see Google banning developers and removing their apps for political reasons, where some lobbying group bombs them with emails
because with this they're explicitly saying they're now choosing who gets to be in or out, there's no way for them to say we can't do anything about it
I do think this would improve security, but I also think it's sort of a Trojan horse to lock down the ecosystem
Banning it from the app store is different from banning from distributing their app on any surface. It's closer to Walmart choosing to not carry a product vs the government saying no one may carry that product. Of course both can happen for political reasons but generally the latter is a bigger hammer applied less often.
Apple's policies were established when you purchased the phone. Apps come through registered developers and their vetting.
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.
They already lost a lawsuit and were fined a hundred billion dollars in the EU for locking down Android. Maybe they think since they already lost once, they can't lose again.
Google had an open (but maybe not perfectly open) platform and is paying out billions in anti-competitive fines because of it.
None of the other platform vendors with totally closed platforms are paying out anything.
So with even a room temperature business IQ, it's pretty clear that closed platforms are the best way to do business, and court rulings in both the US and EU have affirmed this multiple times over the last decade.
This is the remediation to that case and therefore has already been run by the EU. Notably, Apple did not get fined for the way they run their ecosystem which is far more locked down.
Hundred billion would be a quarter's revenue, that can't be right. The lasest I've read is a threat of a fine of around 500mil wrt app store issues back in December, but nothing has been decided yet.
No, you're still allowed to install whatever apps you want, whether they're verified or not, from the system app stores or not. What developer verification brings is the ability to install apps outside the system app stores without a warning, as required by the antitrust judgment against Google.
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.
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.
I think the point they are trying to make is that in the terms of service Google says they get to define what is malware (halfway through article) so the author is trying to point out that exact danger: what happens when Google gets to randomly call things malware.
The article provides enough evidence for that label. Unlike Google, who can arbitrarily call anything "malware". This is the contrast the article attempts to point out.
I have the opposite opinion, Google is doing a lot of garbage in the name of "Security", time to play their game and report their control on Android as security vulnerability
I use Android because it lets me install whatever I want on my phone, which it does not seem to me, controversial. The phone is either mine or it is not. I don't want Google's protection. Particularly, if I can't refuse it.
Well… you can run android without google? The problem is that essential security services require apple or google devices and you as a member of society need the security services.
You can only run LineageOS on smartphones that allow unlocking the bootloader (which is more and more rare), and properly release the kernel source-code (many still don't, especially low-end MTK-based phones...)
Maybe a case for the EU? I mean, they like creating laws limiting the power of big tech. Maybe there should be a law that requires all services that are used by public institutions and commercial transaction providers to be transparent to the public and therefore open source. And as a platform provider, they should be required to offer APIs to let users install alternative implementations.
Might require some fine-tuning, but you get the idea.
Yet on LineageOS you're not affected. It seems you can build Android that isn't affected by Google, at least if you're willing to personally adjust the code to do what you want. You'd have to get exceptionally busy before it's not recognisable as an Android distribution anymore
> I think I’m getting to the point where I’m thinking of ditching Apple again
I would wholeheartedly recommend going for a Pixel with GrapheneOS. I have been an /e/OS user on a Fairphone for 5 years before reading a lot about GrapheneOS and switching to GrapheneOS. It's honestly so much better!
If you go from iPhone to GrapheneOS, you get better security. If you go from iPhone to anything else, you get worse (to extremely worse) security.
You are right. I feel much safer now! /s
I really need to look into those other versions of Android or even Huawei. I have a feeling they might not quite work in Canada. Part of the reason I am incensed about this, is that right now there are all sorts of measures globally, under the guise of safety, that seem to be about something completely different.
While attribution is a strong weapon in fighting malicious software, persevering the ability to install and run anonymous software is essential to fight authoritarian regimes and corrupt systems. If we accept that only signed, permitted software can be installed and run on users’ phones, democracy and our freedom are doomed. Regardless if it is in the West or the East, or it’s against an AI overlord.
We can't make arbitrary changes to much of hardware and software we rely on. We can't inspect their designs, we can't reproduce them, sometimes we can't repair them. Sometimes we can't even tell that they're designed to act against our interests, and, if we do, sometimes we can't do anything about it. We are forced to choose between price and privacy, between interoperability with proprietary (or official) systems and liberty.
Android making another step in this direction is bad. But, let's not kid ourselves: we are neck deep in this cyberpunk serfdom, and have been for decades. If we were to get this Android win, it would be only a small win. I'm saying this not to be defeatist, but to remind us of the bigger fight.
How does this feudal goliath meet its end? When is enough enough?
I just launched an app in the Google Play Store. I did find it a bit weird that I had to provide my physical home address to get my app listed. Not sure what I would do if someone turned up to complain. Make them a cup of tea?
Don’t know about US, but in EU you legally have to publish your address and it will be shown on the store page if your app has ads or in-app purchases.
Anyway, ads are just a sidechannel for purchase. There is a product advertised, someone buys it and developer gets the cut from the seller of the product. This is how ads work.
Just in case they're looking in the wrong place (looks like they moved where this information was since I last looked), you have to expand it in the sidebar on the right.
It's because of a law in California. Don't remember the reason behind it, but Google decided to apply it everywhere. It's also why I let my app die years ago instead of publishing the updated version.
There actually is in some regions. For example in Germany any publication must include an Impressum with details about the author and publisher. This requirement also applies to websites
There is - every server host does KYC and so does every domain registrar (by law). If you're found to have provided incorrect details, it allows them to immediately remove your server or domain without notice.
No there isn't, Google's requirement is to put that information publicly for everybody to see. That's not nearly the same thing as being available on court request.
With that policy, Google encourages stalkers and put developers in danger.
A California law around a decade ago started it (a consumer protection law I think, something like requiring customers to have an address they can contact any seller at), and Google lazily applied it to everyone.
I would have been fine just preventing Californians from downloading my app, but that wasn't an option so I just let my app die.
You should not distribute apps via the Google Play Store. Using alternative means, including F-Droid as relevant. And it was a mistake of you to register, because you're helping Alphabet exert more pressure and control on others.
We finally live in an age when I can tell a clanker that I want an app that does something that I need, connect the phone with adb and in half an hour have a working solution for my tiny problem while knowing little about android development. This is something google should embrace, not kneecap.
Then tell the courts to stop fining them and start fining all the closed platforms.
There is a clear legal asymmetry where allowing competitors on your platform makes you liable if they complain, but blocking out everyone except for yourself is a totally ok and legally rosy way to do business.
Are they such new/fleeting friends that they can't wait 24 hours? Otherwise, it might be a good thing that people can't be persuaded to install an app because a "friend" told them to, and it's somehow so urgent that they can't wait 24 hours.
I'm still a little bit confused why the EU does not take action in this. This is definitely a monopolist overreach which has to be shutdown from the beginning
But they did. EU formally allows all these measures by Google in the name of "security" as described in Digital Markets Act Art. 6 (4) fourth paragraph.
They're allowed to do it "to the extent that they are strictly necessary and proportionate ... provided that such measures are duly justified".
It remains to be seen whether the EU decides that this measure is strictly necessary, proportionate and duly justified. They sometimes do the right thing but I'm not getting my hopes up.
EU will likely want something like this for ChatControl (or whatever it's called in its current draft iteration) enforcement anyway. And Google will no doubt be happy to have its highly paid lobbyists testify on how it will help catch child predators and terrorists.
Indeed. I wonder if it falls foul of labour law. Blacklisting is illegal and whitelisting (certification) is normally done with multiple competing third party certifiers.
this is something the EU would love, it's part of the whole Transparency thing where you dox yourself to everyone
HNers (especially Americans) are super naive and think the EU is some bastion of freedom. no. it just wants to be a huge nanny state but in a wholesome way, where you can do whatever you want as long as it's approved
They'd have had to start with Apple which is more locked down and has comparable market power. Apple fans (iirc like 30% of the voter population) already scream bloody murder when compatibility increases due to legislation and Apple pushes some marketing about how terrible this is
We've accepted that OS vendors can do this for decades. I think that was our mistake: relying on Google as the only available vendor. We can't make a law that punishes Google for having been open all these years. Yes, of course I (like any 'HN' hacker, I'd think) would be in favor of forcing Apple to be open as well, but then it seems that the powers that currently run the EU (and a lot of voters) kinda likes their remote DRM attestation for this digital identification project that you'll soon need for anything not suitable for toddlers and not reachable via a darkweb
Marginally. Apple still approves every app that runs there and can block whatever they don't like for whomever they don't like (or are told to block by a US court, for example). And if you go on holiday abroad and want to take your phone, Apple refuses to tell you what the grace period is during which you're allowed to use the apps on the device.
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)
Emotional talk aside, there's not many good solution to this problem, unless of course F-Droid starts to make their own phones.
But then, Librem 5 Phone was just failed few years ago, telling the story that people who care about their rights are still sensitive to how much they would pay (which is a form of rights too).
Also but, there is the thing, making a phone is not easy. If you reach deep enough, you'll eventually reach the layer where you realize how solid the monopolization has become. The global telecom standards if you read them is in the hands of few companies, Boardcom, Motorola, Huawei, Nokia and such. They'll control whether or not your phone can access the network. Then there's telecom companies who runs the network, and they might have to approve your device/modem as well since they got their channel allocation from the government.
It's not easy, and it's not just the software problem.
Oh and yes, we also have the software problem. Linux, if you want to go that route, cannot be used as a mobile OS, as least not for the public, because the average people don't know how to properly secure their system, and Linux is not a restrictive-by-default system. It will be a malware nightmare if you ship Linux on a phone as is.
The best hope for now I think is for geek vendors to make more mobile/4/5G enabled Fairphone or uConsole-like product to the enthusiast market, and then you can load whatever OS on it as you want.
There is a good solution. A big disclaimer and the user accepting the risk of running the software they want. The same solution they've been doing for years that did not need change. The new developer program is only here because it is more convenient to Google and governments.
You can put the biggest warning on the phone, make it as annoying as possible. Then, the user sees the warning, as well as the fact that all the other people are ignoring the warning, click "Accept" 10 times and got surprised when someone comes to collect the testicle they just donated by themselves.
That's the same reason why desktop computer has so many malwares, that's why phones now has permission systems to restrict what an app can do on it.
If you want to create a system for everyone, including your 60 years old mom and her mom, you need similar of not better permission systems. Linux currently don't have that, and DON'T except an old fashion car mechanic will delicately configure AppArmor etc with his oily fingers in the middle of fixing a client's car.
We've known for literally decades that that doesn't actually work, for several reasons:
1. People are conditioned to ignore warnings. There are way too many benign warnings in the world; you can't read them all.
2. Even when people wouldn't ignore them, in cases where they are being tricked by scammers it's easy for the scammer to talk people into accepting them.
3. Those sorts of warnings aren't actionable. You're installing a new app. It appears legit. You want to use it. You get a warning like "this app hasn't been verified; it might be malware!". What can you do with the information? Absolutely nothing. 99.9999% of users have zero way of doing any deeper check to see whether it actually is malware. Their only options are to give up and go home, or just hope that the warning is wrong. Even I - a highly technical user - get zero value from things like Windows' smart screen. "The app you're running hasn't been signed! It might be malware!". Err yeah sure. I'm not going to reverse engineer it to check am I?
I think their solution of allowing you to disable the restriction with a one-time one-day delay is actually a really reasonable solution. As long as they don't go further than that - the risk is that it is just a temporary placation and they'll ditch that option in a few years.
There's already a restriction that requires going into the settings and flipping a toggle, with a warning. I think that's enough.
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.
It's 2026. This technology has been out for how long?
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.
The problem is easy to solve by making 99% of all apps normal apps that don't get any special privileges and don't require any developer certification, and having a certified developer program with heavily locked down run mode for the 1% of high security apps like banking and payment apps. It's not hard to attest unambiguously to the user in some way whether they are running one of these rare secure apps or a normal one, a restricted API suffices but you could also just add an LED for it.
You can't possibly convince me that Google couldn't develop something like that if they wanted to.
>and having a certified developer program with heavily locked down run mode for the 1% of high security apps like banking and payment apps.
How do you determine/enforce whether an app is a "payment app" without a centralized developer program? They don't require any special privileges. After all, most banking apps have web equivalents.
How does Android know if an apk that nobody has ever seen before is a payment or banking app?
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.
But it exists, has users & is building the case (together with Sailfish OS and others) that having an abusive mobile OS duopoly is not the desirable state of matters.
> because the average people don't know how to properly secure their system, and Linux is not a restrictive-by-default system. It will be a malware nightmare if you ship Linux on a phone as is.
Linux is a kernel. A Linux-based distribution decides what the defaults would be. Why, in your opinion, would a Linux distro targeting phone-ish ARM64 hardware be problematic? Why would it be a "malware nightmare"?
Google won't ever take a break until we all pay for YouTube Premium. I think this trojan horse is mostly because of apps like New Pipe, Vanced, SmartTube and ad blockers in general.
1) side loading, or however it's called, is used by less than 1-2% of global Android users (we can't be more than 50 million). Google made us a favor leaving it open after an only 24h delay. It could be much worse but now it's nothing in our eternal tinkering with developer options. Thank you from me Google.
2) GMS is a huge convenience for any app developer that needs tight control, including governments. They can secure their apps against users of any hat color. Add to that the possibility of hidden backdoors to support surveillance and Google's direct lobbying in EU. This makes it very difficult to go without it, even under the current anti-US EU direction and it will be the last that will be replaced in Europe.
3) There are various levels of "degoogling". From installing a totally open OS without or with microG, to just don't login to a Google account in stock Android. It's a spectrum but someone at the free edge will never have the same rights with one in the jailed edge.
4) Developer verif is NOT to prevent ad blocking. There is a simple and free method to block anything you like at DNS level: just select Private DNS and insert an appropriate URL for ads/trackers/porn etc, eg from controld.com. Find some other justification, like tight user control to continue sleeping with the governments or reach ultimate user surveillance with the upcoming children ident.
> 1) side loading or however it's called is used less than 1-2% of global Android users (they can't be more than 50million). Google made us a favor leaving it open after an only 24h delay. It could be much worsa and is nothing in our eternal tinkering with developer options. Thank you from me Google
It's wild how far we've come, from IBM trying to lock down the PC to truly open hardware, to you now thanking Google for only mostly restricting what you can do with a device that you bought and own...
The rest of your content is just other forms of Google apologia.
This is honestly deeply disheartening... And on "hacker" news of all places...
I don't distinguish a phone from other electronic home devices I also happen to buy. I don't change their firmware for various reasons, like not worth it (eg fridge, washing machine), illegal (eg set top box or car) or impossible. Being able to even enable developer mode in Android and do anything more than designed for a regular user goes already too far in relation to the other devices. Is there any car that you can boost with tapping seven times its gas tank cap? And I am afraid it will be removed someday in the future like the bootloaders became locked one after another. PCs are another story, an open remnant from the past, that the hard and soft tech companies sweared not to leave happen the same mistake again with phones. The term "buy" and it's rights are not inherited from a PC to a phone.
I am not an advocate for the greedy tech companies but I am trying to give some rational perspective of the balance of power between them and us. If we want openness we cannot reach it with wishful saying.
> I am trying to give some rational perspective of the balance of power between them and us
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.
This would be the line for me. If at some point I'm unable to build an .apk and install it on my phone without Google letting me, I'm moving to Huawei.
I'm curious why you think China is actually more open in this regard. The CCP has direct influence over the apps that are allowed to be installed on these phones. There is nothing more free about them.
Low DRM? I looked at Huawei devices because I figured they'd have to sell them here super cheap because of this downside most Europeans people will even see as a showstopper ("how will I install my precious WhatsApp??"), but
- 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!)
not like that no, some US carriers don't allow them though like AT&T blocks you to google or apple phones. for them only pixel supports a way out with graphene.
I wanted to use an alternative mobile OS, but they only support expensive devices like Pixels or outdated models. So I am planning to port some open Android variant. Obviously, all Google Services will be removed and most proprietary apps too. I also want to be able to manually edit permissions and remove Internet access from most of the apps, even open source. It is inconvenient that Android actually has "Internet" permission but doesn't allow the user to revoke it.
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.
F-Droid apps do not need Google Play Services. OSMand (offline maps) and other apps works without it. Telegram probably should work too, but I did not test.
AI also says that it is possible to have push notifications without Google.
Checked my Pixel 7 XL Pro and the app is installed and running (Version 1.0.866414232
com.google.android.verifier). I was able to force stop it, and disable it. Will check later to see if reenables itself.
Btw. This whole debacle made me to stop installing any Android updates. I've done my best to avoid installing even the security updates, so my diabetes apps continue working in the future.
I really need to take the time and go with Graphene OS in this device. My bank N26 kind of still allows it, but they made it harder and harder to use with certain custom checks. Looks like in the future I need a separate banking phone and my daily driver.
The device works right now how I want it. I don't want anything to change.
I have an old $70 test device with stock Android/Google that hasn't seen security updates in half a decade yet all banking apps, electric car charging, Google services, you name it, work absolutely fine.
Meanwhile the daily driver phones of my privacy-aware family members running up-to-date Lineage or Graphene OS with recent kernels and frequent updates constantly run into apps refusing to work for "security" reasons. It's a complete joke.
Google Play Services is independent of Android releases and will update itself automatically, though I believe you can disable this by uninstalling a specific system app with adb.
Android developer verification program, together with recent reCAPTCHA push [1], and Manifest v2 force depreciation on chrome [2], make one thing crystal clear. When companies like GOOGLE talks about things in the name of "your security", it's a sign that they want you to sacrifice your own things, e.g., privacy, freedom, etc., for their own security. And if you trust them and show your consent by doing nothing, you pay the price.
I think this argument isn't likely to go far, considering its use of a type of condemned speech (DEI). Part of the purpose of having ID verification for developers is to ensure that Google can provide information to the authorities so that developers can be held accountable for promoting such anti-government and terroristic ideology.
Article got developer verification completely wrong. The point of developer verification is to be able to install apps outside the app store without warning, which brings Google Android builds in compliance with the antitrust ruling. Third party Android builds can choose other trust roots or disable ADV completely and require warnings for everything because they are not subject to the judgment.
Separately, the process of installing apps that are outside a system app store and aren't verified has also changed, but this is not required by the developer verification feature, and the result seems like a wash to me. The first time you enable installing apps from other sources is harder, but this setting then persists across device upgrades, so the subsequent times go away completely. This now requires developer mode, but apps that check developer mode (I haven't found any in the US) can be mollified with a Tasker task to disable developer mode when launching those apps and enable it again after.
That's only the consumer side of it though. As the post states:
> Should a developer[...] elect to register themself with Google as a “verified” developer, they should expect to sign up for an account and pay a fee, surrender detailed personal information and upload government-issued identification, and then proceed to register the identifiers and signing keys for all the apps they intend to distribute (now or ever).
Those are big impediments to open development. The agreement developers sign states:
> 6.5 If You violate any of the Terms or if You distribute malware or other harmful applications, Google may terminate Your access to the ADC…
But they don't actually define "malware" anywhere in the document. Search HN if you want to hear horror stories about how google handles loose definitions and peoples' accounts.
This is no different from before. If you want consumers to be able to install your app without a warning on Google builds, you have to jump through verification hoops. The only thing that ADV changes for developers is that now they can distribute their apps outside the system app stores without a warning as well, which is a new benefit, not a new restriction.
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.
Can Android OEMs, bundling Google Mobile Services for Android certification, choose different trust roots for verification?
>The correct thing to complain about is requiring developer mode for unverified installs, which doesn't seem necessary
I had assumed the friction was to dissuade developers from not going through ADV. Isn't it partly for making malware distribution more traceable and campaigns easier to halt on GMS/certified Android systems?
Would this also be a strategy to get all Android users to have a Google account? Once you are locked in to using Google's Play Store then can then require login to even install apps.
I don't have a Google account. I never will. If I am required to get one to use my phone(Fairphone4, eOS) then I will cease using the phone. There is nothing in my life that requires me to have an Android phone.
Banking has slowly been transitioning in this direction as they close brick and mortar places. I'd have to drive 20 minutes to cash a check (which is still sadly common in the US in certain industries).
How does this affect the Fairphone? If I buy a Fairphone now (which I've been considering for months now) will I continue to be able to run F-Droid and load arbitrary apps, or does it come with “official” Android that will contain the restrictions?
I would in general recommend against getting a Fairphone. They traditionally have a lot of hardware issues. Some of the early issues on the FP6 (fried logic board while charging and broken volume button) are not user replaceable. Many people have had to wait a month before they get a reply from customer support and even longer to get their hardware fixed. They also completely fail to communicate about issues.
They also have a bad reputation when it comes to updating their software. E.g. their initial Android 15 builds for FP4 had bad memory management issues, with a result that many people could only have one app in memory at the time, which made it impossible to switch between e.g. an app/browser and a password manager/payment app. Some of their updates would cause boot loops when there were fingerprint reader issues, etc. Currently a lot of users are dealing with an issue where apps hang when used over WiFi because IPv6 gets misconfigured when a router sends an IPv6 router advertisement with lifetime 0 (which e.g. Fritz!Boxes that are popular in Europe do). The issue has been there for over three months without any acknowledgement or fix from Fairphone.
Also, even though they do Android Security Bulletins and major releases (though very late), their phones often run ancient kernels and firmware with many known vulnerabilities. This is also the case if you run an alternative OS, because pretty much all of them use upstream trees. Also their firmware has Chinese TCL image processing blobs (might be a security/privacy issue for some people).
I think many of these issues stem from the fact that the development of both the hardware and the software is largely outsourced to a Chinese ODM (T2Mobile), who maintain everything, so there is a lot of delay in everything. My guess is that Fairphone as a company is mostly a PR/support/supply chain auditing (as in minerals/labor, not software supply chain) company, with all the development outsourced.
It depends of the operating system you install.
Fairphone by default comes with a pretty standard Android version with Google Play serices, so it will be impacted.
If you either buy a Fairphone from Murena (with /e/ OS) or from Iode (with Iode OS) or if you buy a standard one and install a version of Android without Google Play Services (like /e/ os or Iode), then you can still use FDroid.
Google already announced the "Advanced Flow" that lets users override the verification. Yes, it's quite complicated, but it shows Google isn't trying to completely close down Android (yet). All this outcry is just lead to a boy who cried wolf situation. ADV is gonna become active, 90% people won't notice the rest will (begrudgingly) use the Advanced Flow. If Google then changes their mind actually does what F-Droid claims right now, nobody's gonna listen.
IMHO F-Droid is just mad because their store model of "developer publishes source code, F-Droid builds and signs the APK" would put immense liability on F-Droid. After all with that model F-Droid owns the private signing keys and now has to register them with Google. If they let a single malware app slide through, Google might designate F-Droid as a malware provider and block everything ever published on F-Droid. (Sidenote: Last I checked F-Droid had nothing in their policies that forbids publishing malware, just that it has to be open source) If you ask me this store model was always stupid and completely missed the point of having signed APKs. I think they also have a newer model where they don't own the private keys anymore, but there's still tons of legacy apps.
Of course Google might have been open to talks about some kind of verified app store program allowing F-Droid to operate under different terms. But that's certainly out the window after all the fear mongering, hyperbole and straight up propaganda F-Droid has put out in recent months.
After many years of Android freedom and choice, this'll likely be the reason I switch back to iOS/Apple. If I'm forced into a walled garden, it may as well be the best one.
I already contacted the DMA authorities and complained how this has an effect on German diabetes communities and they replied that I am not the first one who approaches them on this and they are already investigating it.
I don't get what part of that your think enables them to deny access to third parties distributing their apps on alternate stores. If you're referring to the last paragraph, that very explicitly says that any such security must be an optional setting that is not default. So unless users opt into verified only apps, Google can't force that, according to the DMA.
Maybe not, but reading their blog posts about ADV next to the DMA text, that's certainly the angle they are trying. And it will be years if it ever comes to a court hearing.
And the setting is "optional", just do the 24h-waiting song and dance to change it, or use ADB. /s
If they go through with this, I will make it my life's mission for the coming months to de-google my personal life and break any dependencies on google at work. Done with this nonsense. Shouldn't take more than a month to remove the tumor.
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.
I started de-googling a few weeks ago. I don't really know what I'm doing but it's kind of enjoyable to learn. Graphene OS with F-Droid and I'm most of the way there.
I still use the play store for some apps unfortunately. Also google maps, gmail, google messages (for rcs) and google fi. I'm not sure if theres anything close to the quality of traffic reporting as google maps, so it's hard to give up. The rest I will eventually move away from... Hopefully.
I have a home server with a reverse wireguard proxy for self hosting photos, calendars, etc.
I also have firefox with noscript blocking everything by default, but that's a big pain for an average person. Also it doesn't seem like firefox does a good job of anti-fingerprinting, but I haven't looked too deeply into that.
I even bought a tv that has adb access, and I removed a bunch of bloat, but it doesn't seem possible to remove the google launcher without causing huge system instability. I might just firewall it off.
There are a ton of open source alternatives to google products now, way more than the last time I tried moving away. It's time to leave.
It's nice that you have that luxury, but that makes you an anecdote in a world where folks need a smartphone just to access banking or government services.
It would seem to me that the best hse of resources here would be ensuring LineageOS ports to more devices than Pixels ASAP. Yet no one works on that angle.
What Google is doing is shameful. One of the promises of Android was being more open than the restrictive Apple ecosystem.
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.
Epic games sued both Apple and Google for anti-competitive behavior.
Apple was found not guilty.
Google was found anti-competitive.
In the appeal, Google asked the judge why Apple wasn't anti-comptitive and the judge told them that Apple wasn't anti-competitive because there were no competitors on their platform to compete with.
Google lost the appeal, an inflection point in tech was created, and Google wondered why the hell they tried being open when xbox, playstation, nintendo, apple, all get to do whatever they want on their closed platform.
It's incredible how little coverage that ruling gets despite how damning and detrimental to tech it's implications are.
It's not just shameful, it's stupid. Freedom was the whole point of tolerating the shittiness of Android. If they get rid of that, then there is no point, and I'll just buy an iPhone instead. If I must be in a walled garden, I'll choose the better kept garden, and it sure as hell isn't Google's.
I like Android a lot better. And I really, really like the fact that Android is open source, so that 1) I can read the sources and 2) projects like GrapheneOS can do it right.
Pragmatically speaking, I doubt that the percentage of users currently choosing Android over iOS for this reason would add up to even 1%. Android dominates worldwide by and large because of cost, and unless Apple pulls another Neo this shall remain regardless of how locked down they make it.
lol my god the apple shills are out in full force. this is implementing a tiny fraction of control over probably less than 1% of android users (hint for the hn crowd: you dont represent real people and you need to remember that) in an effort to stop a very real problem that far far far more than the people affected by this face. yet they are worse than apple who has been doing this since day one to 100% of users. you’re an unserious person
AFAIK you can still install any random APK but the process will require enabling developer mode and one time 24 hour wait period. But the problem is many stupid Apps check that developer mode is on and refuse to work.
An FDroid desktop client that adb installs APKs would actually be lovely. I pretty much exclusively use FDroid, but I gotta say I unfortunately find all their frontends to be rather buggy and with very little user feedback when things break (repo updates are hard to observe, downloads hang, updates mysteriously fail)
Droidify sometimes does a weird thing when installing apps:
1. Ensure Droidify is not running.
2. Launch it.
3. Tell it to install or update to an app.
4. Receive an Android system prompt to approve the install/update.
5. Approve it.
6. Tell Droidify to install or update another app.
7. Reveive a system prompt to approve the action of step #3 again.
8. Approve it.
9. Receive system prompt to approve step #6.
10. Repeat #6 through #9 for more apps.
Workaround: Do steps #1 through #5.
Foxy Droid doesn't have this problem, but won't auto-download updates for you.
I've seen more outrage on HN posts about license changes than those related to this. I mean we are in the midst of one of the biggest rug pull of our lifetime and the response was not even remotely proportional. I wish it was a atleast a fraction of what it was during the SOPA act.
Not even businesses that could be hurt by entrenching Google more in the mobile space are acknowledging the issue.
That makes me think may be all the outrage at the SOPA time was probably "promoted" because it aligned with their commercial interests or may be Google is all too powerful and too deeply entrenched that nobody wants to upset them.
If you are in the EU, send a message to the DMA Team. Be polite, explain how Google is using its oligopoly power to shut out competing app stores and applications that can be installed outside the Play Store. Explain how it affects you.
An app becoming unavailable through remote attestation? New recaptcha? Document every case and send an e-mail to the DMA team.
I'm sure there's plenty of Google employees on here, some quite high up.
Push back against these types of decisions internally.
Rally your coworkers against them.
And if you're brave enough, talk to a journalist, or pull a mini-Snowden.
Lord knows the company has secrets.
I bet there's at least one email chain from some exec bragging about how this policy will squash Revanced, ad-blockers, etc.
This started with phishing, poor people being tricked to install apps that then drained their bank accounts. So to resist, maybe focus on that evil? Better international cooperation, better prosecution?
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).
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.)
But it is suspicious they want to defend vs attacks that don't happen while doing absolutely nothing to stop the attacks that do happen. Seems like security isn't a goal here?
(I didn't get scammed, I sometimes am curious on what the scam is so i lead them on a bit)
Are you in Brazil, Indonesia, Singapore or Thailand? Those were the four worst-affected countries IIRC. Although I seen to remember Ecuador or Bolivia as well?
(They do something about other scams too. There was another thing they published recently, I didn't pay attention since no side effect of that concerned me, something to do with caller ID.)
I do think it's about Google trying to squeeze profits out of Android, but is there more direct evidence of this? Cause I always have to wonder if it's something else like KYC.
Of course Google generally tries to squeeze profits out of… whatever it does, but eh, by closing something? Google is the company that makes a million in profit from the openness of the web in the time it takes me to write this paragraph, why would that company think that closing something improves its competitive stance?
By imposing Google Play, rather than letting people use Android without any of Google's ecosystem.
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.
or how about don't allow government and banks and telcos to use abusive apps to provide essential services?
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 frustrating part is that security features often look like malware from a technical perspective. The intent is different, but the capabilities can overlap.
All talk, no solutions from F-droid. What are they actually doing to solve it? Why not stand up their own vetting system? I'd love some technical solutions, instead this is just childish.
By analogy, would complaining about any organization ridiculously more powerful than you (e.g. a government) without having a complete alternative ready to go also be "childish"?
Because as designed they have to live under whatever google puts into Android because they have inordinate control over the whole ecosystem? I'm not sure why or how you would possibly describe that as "childish".
They could register as a corporate developer, but they decline to do so because _"that would effectively seize exclusive distribution rights to those applications."_ But it wouldn't - the course code is still available for anyone who wants to build and distribute the apps themselves.
In the PS3 case the feature was removed fully where in this case you just have to go through a new flow with warnings to reenable sideloading unverified developer's app.
> Disguising itself as the innocuously-titled “Android Developer Verifier” (ADV) process, this trojan horse runs surreptitiously in the background as a system service with full root privileges, quietly awaiting an activation signal. The service cannot be blocked, disabled, or removed. Unlike a commonplace bit of malware, this extraordinary strain won’t be detected and neutralized by Play Protect (the malware scanning and remediation service that is installed on all Android Certified devices). In fact, Play Protect is itself the vector through which this virus is transmitted and installed.
> That is because it is Google themselves who is propagating ADV. And once activated, this malevolent process has exactly one goal: to block you from running software by developers who haven’t been approved centrally by Google.
The rest of the article is a claim that Google's new terms of service amount to "malware is any software we [Google] don't like."
It seems like Google is aiming for its own walled garden.
I think it's funny that they look at the phrase "malware or other harmful applications" and then only have an issue with the definition of "malware" rather than "harmful". Like, wouldn't "harmful" be FAR easier to apply in literally any case you feel like? "malware" sounds like it'd need some proof of malicious intent but "harmful" needs no such thing and is much looser.
The temerity of Alphabet to claim to protect users from malware/spyware, when they are known to share all of your personal information and communications with the US government (Snowden revelations), is the epitome of hubris. And, also, in the world we live in, just another Thursday.
But even ignoring this - it is not for Alphabet/Google to decide whether, and how, I want protections. I want to be able to pick a sequence of bytes and install that as an application on my phone, without Alphabet having any say in whether that happens or not, and in fact without them knowing about it. It's my phone, not theirs, and the software should help me do what I need/want, not help them provide me their often-questionable services.
It's even worse when Google believes they have a legally defensible justification that your data has been "anonymized". E.g. "anonymized" location data directly from your phone that just so happens to be accurate to the meter. Such data just cannot be anonymized.
I've already disabled Play Protect ages ago because it kept removing apps I had installed through F-Droid. Actually, I almost only install apps via F-Droid. I wonder if the ADV will install with Play protect disabled ?
Maybe I've too much faith in Google, but a part of me wonders if Google doesn't want to get sued for this change. After all, their competitors have similar systems. While Microsoft's is circumventable with a few click-throughs, it's particularly nasty in that their code-signing certs are comparatively brutally expensive, too much so for hobbyist projects generally.
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.
While I hate how user-hostile stock Android is (and it's getting worse, all because of Google's ad business model), these reactions are so blown out of proportion they might only teach Google to do it the subtle way, or use such changes as a smokescreen..
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.
My iOS using friend told me that he can't even use the iOS software that he has written on his own phone. He can run the software but it expires in a week so he'd have to redeploy every few days to keep it running.
Is that right? Is that the future of Android as well?
It is time to dismantle - and subsequently forbid - Google. Too much Evil is now concentrated in this greedy adCompany. Mass-infecting so many devices on purpose is beyond compare now.
We already have the OS, what we need is a company that is willing to take a bet on it, support it and convince hardware vendors to provide upstreamed drivers for their stuff.
PostmarketOS may not be perfect as of now, but it would advance and progress so much if people were hired to work on it and if people could buy a smartphone with it preinstalled. Bug reports and corrections would come much quicker as well as supported apps. Right now it is just a confidencial toy OS because of the lack of hardware support really, only a small number of smartphones are supported, only 2 of them are still sold and available as new (pinephone and pinephone pro), their specs are nowhere close to what you would expect for the price and they are only sold through a rather confidential online store.
>Should a developer — contrary to our recommendation — elect to register themself with Google as a “verified” developer, they should expect to sign up for an account and pay a fee, surrender detailed personal information and upload government-issued identification
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.
> 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 F-Droid, one of the most famous malware dens in the Android ecosystem.
I think the most fun part with Google is that if some wayward algorithm decides it doesn’t like you, along with nuking your app and developer account it will probably nuke your 20 year old gmail, your kids Google Drive accounts, your wife’s YouTube premium, the Adsense account of some company you worked for in 2008, and disable your Nest cameras.
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.
Meanwhile, private Google services charge me the wrong prices, because I have a Payments profile in another country. It is associated with a Merchant account, which is linked to the Google Play Developer account.
The support concluded that this can also not be closed, and that I should close my Developer account first.
It's not just google. Try removing an unpublished but uploaded iOS app. Wasn't possible for decades and I guess it still isn't. You eventually could hide them. The only way to remove it was to publish it, but that requires app validation, which a failed app is not suited for.
Suing a company will almost certainly result in them exercising their right to not do business with you and shutting down all your accounts - exactly what OP was trying to avoid
In some EU countries - it could be seen as retaliation if you sue for something and then Google closes your accounts, some EU countries have strong protections here.
More importantly for Google though it's under extra scrutiny under the DSA at the EU wide level - so it doesn't have a clear right to not do business, it has to do terminations correctly with clear reasons set out in terms, there are mandatory notice periods etc.
really? I have to keep making useless updates (just a version number bump) on one of the accounts i manage, because i keep receiving thread emails every 6 months that the developer account sees no activity and if i don't do anything they will remove and close.
that app is a done project and need only to be udpated when the target SDK becomes too old for the play store
What happens if you "accidentally" become persona non grata with both Google and Apple?
If you want to participate in the society, you will forever have to resort to shady tactics. Shady can be defined something as arbitrary as using GrapheneOS.
A temporary workaround like using alternatives like GrapheneOS for those affected will only delay the inevitable but it doesn't stop it at all.
If you've accidentally become a persona non grata, then obviously because you've not exercised sufficient self-censorship.
This is real already. Recently saw a petition for EU to rein in big tech (there are several initiatives advocating this). Had this nagging voice at the back of my head ... what if signing that gets your Google Account terminated.
I'll leave it open to you whether I signed it.
For developers relying on any type of Google services, you'd be in for lots of pain.
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.
I was in that situation a few years ago. I started a hemp related business in 2019 and Ad Sense didn't like my ads and gave me an error message saying I couldn't run my ads because of certain keywords being banned. I forgot about it until a couple of years later when I saw a $300 charge on my credit card bill. Google changed their policy as CBD/hemp had become more mainstream and started running my ads. By this time my business had already failed so I did not want those ads running. I couldn't figure out how to contact a human, so I ended up just paying because I didn't want to risk getting my account closed.
> What if Google reinstates their old G+ and YouTube real name policy for its accounts.
G+ was a failure; people refused to provide real names. Even Facebook's "real name policy" wasn't (and still isn't AFAIK) enforced at all. At one point, I had multiple phantom Google and Facebook accounts. Now I just self-host and eschew social media.
>Google had Don’t be evil motto just between 2000 and 2018.
this is popping up a lot today for some reason. "don't be evil" is still in the code of conduct, as it always has been. it just isn't in the preface anymore after the restructuring under alphabet.
To some degree, the closest we have to these situations besides getting flagged with TOS violations (whether real or false-flagged) in these companies are residents of countries that are either trade or economically sanctioned by the USA.
Thankfully we haven't seen something like an account ban and deletion incident for such cases, but the severe ones I can remember usually prohibit access entirely and that'd be scary if it extended to primary services that others rely on for auth.
You will be effectively locked out to services if it's all that's linked and that identity provider just decided you'd be persona non grata.
iOS can be used without an account. iPhones can be acquired outside of Apple. The EU has the alternative App Store option that doesn’t require an Apple account.
But I can't use my Norwegian BankID unless I have an apple store or play store account. This is required for every aspect of society. Heathcare, banking, taxes, driving, using my debit card online.
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.
We need all countries and the EU govs to mandate companies to provide the same vital access via a Web page that works on the 4 major browsers (not an issue anymore) as via the app. All my banks have it; I need an otp device but thats fine; it works well. I wish EU would mandate that plus an EU made hardware device on which all seeds can be stored and otps generated. That can be the size of an USB stick you can put on your keyring. Add NFC/qr so you don't have to type the otp and there we go.
Most places are going the other way. The UK uses ID verification for company directors that gave me an alternative between driving half an hour each way (plus parking and queueing) or using a mobile app. There is a web version but apparently they do not have the data to let me use it. The EU is pushing an age verification app that will only work on Apple or Google phones.
There is a huge push towards cashless payments that has the same effect, especially as people increasingly use mobile payments.
That's on your bank and not necessarily because of Apple/Google duopoly. I think it is crazy to put the whole banking system on foreign, private company though
It's not on their bank so much as the entire banking system in Norway and the rest of society tagging along for the ride.
BankID is used for login with every single Norwegian bank and government institution. There are alternatives, but they're invonvenient and sometimes bespoke per service.
It truly is. We are a completely digital society and everything is authenticated with BankID. The name is a misnomer, it's not just banking but every single government service (including healthcare).
I might be wrong but as far as I'm aware there's no legitimate APK downloads. And even if you get a hold of it, they use google services to attest the phone is secure, so there's no running it on a google-less OS.
The workaround used to be SMS codes, scratch off cards, and a physical 2FA codebrick. They cancelled SMS and the card, and currently you can't acquire a codebrick until they figure out some new bullshit about ID verification. Even the app is warning us it will quit functioning if we don't submit a passport and biometric face scan to some private company: https://bankid.no/en/help/confirm-identity
What Norway has sounds pretty crazy to me. If I am reading this correctly, Trump can disable the entire Norwegian healthcare system by calling Apple and Google and having them block BankID.
Trump can close down a lot of the British NHS by telling AWS to stop supplying it. Everyone apart from a few countries (China, Russia, Iran, North Korea, etc.) is dependent on the US.
> The EU has the alternative App Store option that doesn’t require an Apple account.
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.
You can't install anything without an Apple account. Just tried installing altstore.io to repeat my previous unsuccessful attempt.
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".
Wow, I did not know this and -despite its drawbacks, like not being able to install apps from the Apple App store- this seems like a great way to have a powerful dumb-phone.
It's not Linux phones that we need. We already have alternatives, like graphene and other AOSP forks.
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.
The irony is none of this is a problem in the US. We still have a ton of banks that you can use without a smartphone. Even my bank's app works fine on a rooted Android or GrapheneOS.
I just recently, in the US, got bounced through a bank authentication system (Wells Fargo's) when trying to order something from Amazon that required me to use their mobile app. I don't use an Android or iOS phone; as best I can tell there is no way to successfully complete that authentication. I even have a hardware TOTP token from the bank now, but even that they won't accept.
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.
As a natively Russian speaking Jew born in Crimea I really don't need any lectures on democracy from someone who ran away to Europe at the height of it's American enforced century of stability. My childhood was listening to stories from my great grandmother (born in Moldova) losing her entire childhood and several family members to European savagery. European so called Democracy isn't even one lifetime old. It's hilarious that you think Europeans have any moral high ground here whatsoever. It took the US to save Ukraine from the Russians and while the entire EU was waffling and talking about "escalation" we were actually doing something about it.
You say that as if Norway is somehow super civilized and enlightened when it comes to these things, that's not the case. Norway is best in class when it comes to compliance.
The new base agreement with the US, for instance, for practical purposes declares several areas in Norway to be US territory. It's rampantly against the Norwegian constitution of course, but that doesn't matter because the parliament seems to have agreed to just unanimously consent and not talk about it further.
Sea bed mining was a farce. Everyone said it was a terrible idea, including Equinor itself. Approved anyway. My assumption is that someone from US/NATO whispered "strategic minerals" into some party leader ears, and they suddenly decided to fast-track it without further discussion.
It would surprise me a lot if there weren't similar fast-tracked, no discussion, "it has been decided" deals about digital sovereignty. Norwegian politicians may not like the guy currently in charge over the Atlantic, but they view him as a temporary aberration and an occasion to prove their loyalty (to the crown, rather than the guy currently wearing it).
Speaking from experience, it's not only ID systems but if you run non-Android (some AOSP) they might still require you to install an App only available with Play Services or on iOS to do business with government agencies or even apply for funds in some European states. In other words if you are using GrapheneOS, from gov. agencies point of view you might as well be a criminal. Actually given how frequent ID-theft is nowadays, it's actually easier for criminals to launder their money than privacy preserving individuals or companies to pay taxes in EEA.
GrapheneOS does not run anything through google services. Nowhere in the "terms" is this stated. GrapheneOS uses first party servers for all default OS connections.
You seem to be greatly misunderstanding what is actually happening.
You are conflating default OS domains with google play services. Google play services is not bundled or installed by default, and is not given any kind of privileged access when it is installed. It does not handle OS domains or functionality, and GrapheneOS does not proxy its connections in any way.
As for the default domains of the OS, most are to GrapheneOS servers, not proxies. The only default OS connection that is proxied to google is remote key provisioning.
As for non-default connections, the only google proxies are widevine, for apps that use widevine, and SUPL, for location locking. SUPL can be disabled, and GOS is considering removing SUPL if network location is effective enough, or if they can host their own SUPL server viably.
> every app installed is known to the proxy since each app has a unqiue key
GrapheneOSs proxies do not collect and send any "unique keys" from apps. That is made up.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
They dont mention a proxy of RCS data because there isnt one. RCS messages do not require location data. None of the GrapheneOS proxies are related to RCS and the proxies do not know if an RCS message is received or sent.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
You did not read the FAQ at all.
> There is some vagueness regarding the RCS implementation message content. People claim Google can't read it, yet they specify they can read it in the client terms, and offer a managed RCS archiving service that works regardless of messaging client or supposed encryption. Is the RCS query proxied? Graphene does not mention it, but the simultaneous location data to use it is.
RCS is end to end encrypted on Google messages. The RCS spec also includes end to end encryption. There is no RCS proxy and RCS is handled by google messages. No other client for it exists at this time. The location data provided by SUPL is not given to apps, it is used for OS location that can be reported to apps. An app must have the location permission to have location data provided by the OS.
> every app installed is known to the proxy since each app has a unqiue key
No such proxy exists in GrapheneOS. GrapheneOS does not intercept or proxy connections made by Google apps or other apps.
GrapheneOS doesn't include Google Mobile Services. Sandboxed Google Play is not part of GrapheneOS. Users can choose to install Google Play services, Google Play Store and other Google apps on GrapheneOS. Unlike a standard GMS Android device, those are installed as regular sandboxed apps with no special access. The feature provided by GrapheneOS is a compatibility layer coercing those to run as regular sandboxed apps if installed by users. It doesn't involve intercepting or proxying any connections.
> location data is proxied
Location request rerouting is an entirely local feature of the sandboxed Google Play compatibility layer. By default, it replaces the Google Play location library used by many apps with another implementation using the local OS location service instead of the local Google Play location service. This isn't intercepting or proxying connections.
Google Play has an optional network-based location service that's opt-out for a GMS Android OS although it's opt-in for sandboxed Google Play and people would also need to grant the required permissions to Play services which aren't normally needed.
GrapheneOS has an opt-in network-based location using Apple's service either directly or via a proxy. We'll also eventually have our own service with offline database download support as another option. We have to build our own database to use for this first.
You're misunderstand what location request rerouting means. It reroutes apps which normally request location from Play services to ask the regular Android location API for it instead. This doesn't involve servers other than optional network-based location for apps which support using the network or fused providers. Network-based location is opt-in for GrapheneOS.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
GrapheneOS doesn't proxy things in the way you claim in the first place. It doesn't proxy any connections involving carriers and doesn't proxy any connections made by Google apps. It doesn't come with Google apps and those would need to be installed by users.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
This is all completely untrue. GrapheneOS doesn't include with sandboxed Google Play. Sandboxed Google Play compatibility doesn't make any connections to GrapheneOS servers. It doesn't proxy anything through our servers. RCS via Google Messages doesn't involve our servers either.
You're misunderstanding our approach to all of these things. Location request rerouting means replacing the local Play services location API for apps using it with the OS location API. That means asking the OS for location rather than Play services. That isn't a connection to a server. It means that by default, apps using the Play services location SDK will work without Play services needing to be granted Location access based on the OS satellite-based location. If users enable network-based location for the OS location service then it will work for apps normally using the Google Play network or fused location providers. It's an entirely local compatibility layer as with the whole rest of it. Sandboxed Google Play compatibility layer has 0 connections to our servers and there's no reason it would need to connect to our servers.
> Graphene proxies all the Google services connection. They take over the connections that would go to Google. They then, supposedly, only forward the ones you wish.
GrapheneOS doesn't include Google Play services. Unlike LineageOS, GrapheneOS replaces all of the standard Android Open Source Project (AOSP) connections with our own servers. Also unlike LineageOS, GrapheneOS adds toggles for these connections providing a way to disable the ones which didn't already have a way to do it. See https://eylenburg.github.io/android_comparison.htm for a comparison across AOSP-based operating systems covering what's done with most of the standard AOSP connections. It doesn't cover everything such as the Certificate Transparency (CT) log list downloads added in Android 16 which are now used by default for enforcing CT for apps targeting Android 17.
> Graphene proxies what would go to Google on regular Android.
GrapheneOS doesn't include Google Play services. It has a compatibility layer enabling running Google Mobile Services apps including Google Play services and Google Play Store as regular sandboxed apps, but it doesn't come with those. Users can choose to install those in specific profiles.
> I am getting downvotes on this, but that is how their Google Play sandbox works. It is proxied on their server, not your phone.
>
> A non-Google copy of your Google pointed traffic is made. That is a fact. It is identifiable to you or they could not individually forward this or that. That is a fact.
GrapheneOS doesn't include sandboxed Google Play. It does not come with it. It's possible to install those apps on GrapheneOS and it provides a compatibility layer to make it work. The compatibility layer doesn't involve proxying anything to our servers.
> Extricating from Google is the answer. Not relating your RCS chats et al through a third party then to Google then to that third party and back to you.
No such thing exists in GrapheneOS. It doesn't include any Google apps and doesn't proxy any of the connections made by Google apps elsewhere if people install them.
GrapheneOS has low-level support for RCS but doesn't have an RCS app yet since the only one for Android which exists in practice anymore is Google Messages and Google apps aren't included in GrapheneOS. Google Messages can be installed by users on GrapheneOS and set as the SMS/MMS/RCS app instead of using our fork of AOSP Messaging but that's definitely not a default. We'll have our own RCS implementation in the future in our fork of AOSP MEssaging.
> They wrote an article on it a while back.
No, and it's definitely not how sandboxed Google Play works for people who choose to install it.
It sounds like you're misunderstanding what our sandboxed Google Play compatibility layer handles location requests made to Play services. For users who install sandboxed Google Play on GrapheneOS, our compatibility layer redirects apps requesting location from Play services to request it from the OS instead. This doesn't involve making any connections, it happens locally on the default. By default, only GNSS (satellite-based location) with A-GNSS (SUPL and PSDS) is used. GNSS is a receive-only system. We add toggles for configuring SUPL and PSDS with choices between GrapheneOS, Google or Off. PSDS are static database downloads covering the whole world so that's just another form of update download. We also add a toggle for opting into our network-based location implementation which uses Apple's service either directly or via a proxy. You seem to be confusing our location request redirection with intercepting connections and running those through our services which isn't what it involves at all. Our location request redirection avoids needing to grant Location access to Play services by making it use the standard Android OS location service instead as many apps already do. There's a toggle for this in case someone actually wants to use Google's location service with their network-based location instead of Apple such as if the Apple data for their area is awful.
> Graphene with Google Services is like calling up an Intel Agency and signing up to use them as your VPN.
GrapheneOS doesn't include Google Mobile Services, and our sandboxed Google Play compatibility layer doesn't work that way at all.
> Without Google Services, it is a way to degoogle a phone with an SD card slot and 3.5mm phone jack if Motorola continues on track, but I would prefer regular Lineage support than Graphene for that purpose in case the middle man aspect expands to non-Google Services apps later.
There's no such man-in-the-middle system in GrapheneOS as you claim. LineageOS does not replace the Google servers for all of the standard AOSP services as we do and doesn't provide similar settings to control all of those. GrapheneOS does not intercept/redirect Google services used by Google apps as you claim. It doesn't come with Google apps as you're describing either.
> I want straight no-google android with the chipset drivers so that calls and sms/mms messages work without Google getting a copy of every message sent and received, and I want it on phones with sd card slots and 3.5mm headphone ports.
GrapheneOS only includes support for using SMS/MMS via the carrier. There's no involvement from Google unless Google is your carrier or your carrier is using GCP to host their servers or something similar. Using Google's RCS services would require that you go out of the way to install Google Messages after first going out of the way to install sandboxed Google Play followed by setting Google Messages as your carrier-based messaging app and granting the required permissions to use RCS (Phone permission for Google Messages and Play services along with the ICC authentication toggle in the sandboxed Google Play settings).
You're talking about it as if us supporting installing these apps as regular sandboxed apps somehow makes that the default approach. That's not how any of this is supported at all. You have to go out of your way to install sandboxed Google Play or especially Google Messages. Those don't come with GrapheneOS.
GrapheneOS does not include Google Mobile Services or Google Messages. It does not intercept or proxy connections made by Google apps installed by users. None of that is part of how it works.
There are no such terms. In a comment further in this thread, you linked to inaccurate posts from an anonymous user on the Privacy Guides forum as your sources.
> They still run everything through Google services.
No, this is completely untrue. GrapheneOS doesn't have any mandatory connections in the first place.
> They are essentially a man in the middle to Google services.
No, GrapheneOS is a privacy and security hardened mobile OS. It isn't a proxy service and doesn't have any mandatory services. It does not come with Google Play services.
> I read their terms to mean that they could snarf everything that every graphene device would normally send to Google because they are "anonymizing it" before sending it to Google.
There are no such terms despite what's claimed in the incorrect anonymous posts you read.
> What we need is Android like Lineage that works on more devices than Pixels and simply have it without Google services at all.
GrapheneOS doesn't add a single Google service compared to the Android Open Source Project (AOSP). It replaces all of the standard AOSP default connections with our own servers by default. It also adds settings to control each of the connections. These settings mostly have a choice between GrapheneOS server, Standard (Google) server or Off.
LineageOS doesn't provide replacements for the Google services pr toggles for user control. This is covered in the third party comparison at https://eylenburg.github.io/android_comparison.htm which provides an overview of what's done with most of the default AOSP connections. The table doesn't cover all the standard connections, but GrapheneOS does deal with all of them by replacing the standard servers and provides settings to control the connections.
We add opt-in services for geocoding and network-based location as an alternative to the Google service. We host geocoding ourselves with Nominatim using the standard OpenStreetMap, Wikipedia and other supplementary data. Our network-based location service has a choice between Apple or our proxy to Apple but we plan to build our own database to host it directly.
SUPL which is a limited form of network-based location has a choice between our proxy to Google, Google or Off. SUPL can be fully replaced by enabling network-based location and leaving the default enabled static global PSDS database downloads enabled. We'll be hosting our own SUPL server using our network-based location database once the much easier to build subset of the database for cellular towers is ready for use.
Google certified devices use Google's hardware key attestation root and service so supporting that inherently has to use either a proxy (our default) or their server including for a non-Android-based OS running on the same hardware which wants hardware attestation support to be functional. That's tied to the hardware ecosystem based on certification, not software. Non-Google-certified devices will use a different service for attestation key provisioning, either hosted by GrapheneOS or a proxy to the service by the hardware provider or certification authority.
Why do you need a Linux phone (as if Android is not a Linux phone), when there is also AOSP. If Google closes it up, it can be forked, but I don't see any fundamental benefit of throwing away decades of development done on AOSP.
GrapheneOS is not shady at all, since when is wanting to use an actually secure OS that doesn't sell your data to palantir or some other ACTUALLY shady shit like that shady?
The US made a Canadian judge a persona non grata for any firm domiciled in the US. All because she works for the ICC, and the ICC declared Netanyahu a war criminal (which is indisputible). Why is the US destroying worldwide trust in US businesses on behalf of a reviled nuclear armed hermit nation on the other side of the planet? Good question, but it is what it is.
This example that the US will spuriously use sanctions like this is why many nations are investigating ways to purge American financial systems and tech.
That judge may be an outlier today, but we all know tomorrow they could sweep through all accounts and ban everyone that spoke against the regime. We have arrived.
You are right - now greedy corporations decide who is an "acceptable" human and who is perma-banned.
Governments need to wake up to this insane level of Evil. And other governments also need the US government responsible here, since they allow this to happen.
In objective terms this can be called a fascist system.
> A temporary workaround like using alternatives like GrapheneOS
The issue still is that so many services and functionalities are tied into private companies. States simply need to wake up now.
> Governments need to wake up to this insane level of Evil.
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 need to wake up to this insane level of Evil
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.
As proven by history, it's convenient to have a big well-known external entity to blame as a source of any trouble, but in reality it's orders of magnitude easier to be a digital dissident in the US compared to the EU. And European Commission + European national governments are exactly the ones you should blame first. They are openly proud of how it works, they call it successful digitalization for a positive spin.
As an extra anecdote: one of the things Cory Doctorow has been bringing up as a counterweight to US tech hegemony has been repealing anticircumvention laws that the US insisted upon as a condition of tariff-free market access that has now been rescinded. This is a good idea, but at the same time, the EC is never going to do it. We're already seeing with Stop Killing Games how even tangentially related consumer protection issues can and will be shot down with an insistence that IP is sacred and untouchable.
The reason for this is really simple: every pirate wants to be an admiral, and every client state wants to be an empire. We as tech consumers hear "sovereign cloud" and think "cutting out undue influence that US tech companies have in the EU". The EC hears "building our own tech monopolies to lock in other countries into our stack". Using SKG as an example again, the whole reason why SKG started was because of a French company, Ubisoft, killing one of their games. Why would the EC ever overrule their own industrial interests?
The EC was specifically and expressly built to be an antidemocratic bulwark against popular sovereignty. The entire concept of dividing people up by nation-states is already an antidemocratic exercise - e.g. France has 69,000,000 residents and Malta has 520,000, but both get one seat at the EC. And because the EC is made up of nation-state appointees and not elected representatives, they have all the incentive in the world to stab their own people in the back. The EC is the designated villain that the """liberal""" side of Europe's government uses to shut down democratic control (and, sometimes, even liberalism itself).
Some have pointed out that this is deliberate (and, supposedly, therefore good): that Malta would never have joined the EU if they didn't have veto powers over whatever France wanted to do. My counterargument is that veto powers are the last resort of the rich and powerful. You can either have strong protections[0] on national identity, or you can have democracy, but not both.
[0] To be clear, the way we deal with democracy being a tyranny of the majority is with liberalism: we explicitly declare certain things to be "human rights" and thus more or less off limits to the democratic process. This list is generally fixed (or at least, difficult to change) and thus less ripe for abuse than, say, having an entire wing of the government dedicated solely to overruling the people that is active all the time.
He never had WhatsApp. He refuses to use google. Only till recently he started using signal. He has been using an old Nokia phone till he was forced to upgrade by his operator. He is European and here in Europe WhatsApp dominates. Despite all that and having a very social life, driven by work, he manages.
I recently ordered a Jolla phone. I don’t want to know about android. I might tolerate iOS. But shelling thousands of $ for a phone that is controlled by an external company…
I am looking out for messaging alternatives. I am at a point where I think linking your identity to a phone number is not right either.
Let’s say we should all wake the fuck up. This is not right. Having a phone with such spyware is a potential attack vector I don’t want to have on the most important device I own.
It's all good until your European bank starts requiring unrooted Android and iOS for their mobile banking app, then tries to force you to use that app instead of letting you sort things out at their building. Then the government starts requiring you use unrooted Android or iOS to sign into their website for administrative tasks, and so on.
Then I'd switch bank. A lot of banks work with SFOS [1]. Given the way the US is acting, we are trying to lower our dependence on American services, and I very much doubt all banks will walk the US bandwagon. There's a serious market for something else.
Right, until you have to use a mobile app to pay for parking or validate your bus/train ticket and so on. Yeah, "I can use my physical card", for now. Long-term we need a better solution than keeping an extra up-to-date phone.
Malware on Android causes more harm, both to individuals and collectively to all Android users, than Google locking people out of their accounts. These aren't even in the same order of magnitude. There are countless examples of people who have lost their life savings, all their data, etc. Losing access to your Google account sucks too, and I don't necessarily agree with what Google is doing here, but you're completely off base here.
If it makes my phone, that I paid for, do things I dont want it to do then it's malware.Especially because those things make the device less useful to me.
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.
Infomaniak (swiss) has a decent deal of a couple of free mailboxes with any domain you own through them. The webmail client kinda sucks but I just sync it with native clients. Using username:password for SMTP feels pretty weak tho they don't have Oauth2 support. lol now I'm talking myself out of it but it's worked great for years.
All service providers above some scale should be obliged to create a transparent processes or be taken for external jusges.
Even better: all providers of services with more than 100K users or 10% of country internet users should be forced to provide API to export / import data in open format.
Maybe service providers above some scale just shouldn't exist, period?
It would be a lot harder to erect walled gardens if you're only serving a small subset of users - they would balk and leave at any attempt to prevent them from interacting with others outside of the ecosystem, and it would be a lot easier to do so.
That happened to me, lost 16 years old gmail account, which is my main account for my digital life. It happened after I disabled some tracking, and Google was no longer able to recognize me, even though I had my phone number registered, it was not enough.
I suspect this will happen to me soon, though all I do with it is occasionally sign in just to keep it registered. It now refuses to log me in unless I am on a specific IP address, no matter how many MFA steps it requests and I pass.
Same. Lost my 2004 Gmail because they silently enabled 2FA and the phone number on the account is a long lost one. I have the username/password and the recovery email is set to me. The account also forwards all emails to me, so I still get the mail, but I can't log into the account.
Not yet found someone to do a SIM swap for me and get the 2FA code...
This almost happened to me 4-5 years ago. I don’t recall every detail but right around the time I was deep into a new job interview process, Google Pay decided it needed to verify my identity. It may have been triggered by one of my cards expiring but I don’t think I had ever used the service to actually pay for anything at that point and just had a card saved. Anyhow, I was almost immediately locked out of my primary email account as well and got delayed in sending documents to the potential employer and had to explain that I got locked out of gmail. Unfortunately, I didn’t learn my lesson and still use that gmail account as my primary email but I did at least open alternative accounts on other cloud providers.
This has been known for quite a while; when I published an Android app ~10 years ago I saw lots of people advising you to create a separate Google account to publish apps under, because a robot can just terminate your entire online identity for the crime of trying to contribute to Google's app ecosystem.
I left behind Android and as many Google services as I could in 2020 and so far I've only been more vindicated with that decision over time.
I've seen multiple stories of people buying phones from Fi, the phones never arriving, google refusing a refund, and on a chargeback, their entire google account gets shut down.
I still use 2 Google services, of which neither would crumble me if lost (YouTube, and my old email which now acts as my spam inbox). I have lost accesses before, when I was still partially dependent, and had to give up my privacy to get access again, long enough to get off. It sucks but I do consider myself lucky that I was able to prevent the life crushing consequences that some people have had. Such a terrible company.
Leadership at Google should face prison time for this sort of practice. We wouldn't accept it in the physical space, so why do we accept it cyber space?
Have a friend lawyer that will send them a proper letter. They will take you seriously that way. And if you live in EU, use GPT... Actually, use Gemini (!) to craft another great response invoking a number of articles etc that they are in violation of.
We experienced this with Anthropic, not the same blast radius obviously, but out of nowhere account was terminated. No support available.
It was via someone’s 30+ year old classmate via LinkedIn the account got reinstated.
As a counterpoint to the right to the repair there should be a right to recover.
There was a more direct case where someone’s child had been interacting with Gemini inappropriately resulting in Google nuking the entire families Google accounts.
Google has been nuking accounts since their inception.
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).
> Google has been nuking accounts since their inception
Google has been dealing with accounts opened for fraud, spam and other evil bots since their inception. They should be nuking those. What's needed is some way of reverifying an account that was closed incorrectly, maybe some kind of independent ombudsman service or something to get the account back.
This is why I don't mess with any of Google's AI offerings right now. Losing access to my Gmail (technically a google apps for our domain) account would be devastating. I think the risk that some google ai decides I'm abusing their ai and bans me is too high.
You go self-hosted and try to stick to real small alternatives, subset of technical standards, etc.
I am not a US citizen, but a EU one (well, since we have seriously rogue and toxic EU states, I dunno how long it will last).
And guess what, the handling of the issue of technical interop for administration online services is done... at the top of the top of the political power: in my EU country, only the president and prime minister do define it. Yep, you read well, it is THAT MUCH important: parliament, no power over it, 'technical authorities' have actually no real power over anything, etc. It requires the same level of power than deciding to make more nukes.
Basically, in 2015/2016 our president/prime minister at that time literaly gave all the administration (and dependencies) online services to big tech (a technical document which is basically 'law' with a content 'opening the gate' for big tech). Well, I say 'they gave it', but they could have 'sold it'... we have a department in our DOJ to monitor past politicians who could have set up some public money channels in order to benefit from it, often indirectly, afterwards. The following president and prime ministers did change nothing... how deep the rabbit hole goes? Brain washing via hardcore lobbying? Corruption?
IRL, you had country administration related web sites, working more that fine with "any browsers", small and big, citizen made, small company made, now it is over, they were all broken for web apps which do work only with whatwg cartel web engines with their abomination of "computer language" requiring an even worse SDK. Same with file formats.
There is light though, if this document of technical 'law' is properly modified, the whole administration and dependencies have 3 years to restore simple web sites and support minimal and subset of file formats.
While I sympathize with the general negative outrage towards this change, I truly believe that people here fail to empathize with the mainstream users of Android phones.
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.
The only time I've actually seen Android malware in the wild, it was because my mother installed a homescreen flashlight toggle widget from the Play Store that also displayed ads on the lockscreen. That was forbidden under Play Store rules, but there it was. I replaced it with something from F-Droid.
The Play Store still has a problem with shady apps years later. If Google wants to be more like Apple, they should start with better curation in their own store.
They can lock down the Play store completely, that's what 99% of people and the people most vulnerable to malware are using. The problem is extending that to F-Droid and other alternative services.
I’ve seen a fair bit of bloatware, spyware and what I’d count as malware on people’s Android phones. Every last piece of it has come with the OS or from the Play Store.
This is exactly why I use Android over iOS, for software freedom. If Google forces ADV and locks out F-Droid, they remove the single biggest differentiator between the two platforms. Making Play Protect into a forced gatekeeper instead of an opt-in security scanner is a massive bait-and-switch for users who care about digital sovereignty.
> How long before they designate all ad-blocking software as malware, block installation on all Android certified devices worldwide, and permanently designate all developers of this class of software as malware creators?
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.
Plus, it is not the bottom I fear, it's the precedent from letting companies slide down the slope.
Regulation may try to stop it but history has shown some have slid to the point of no return or past a point where people can care enough to build out of.
Prevention is better than retroactively fixing stuff.
I alternate my thoughts frequently (which I believe is healthy), and sometimes I think we should let things take their course a bit more before reacting. It's certainly tiresome and can be pointless (some people claim 'hysterical') to fight lots of changes, not necessarily this one but some like it.
But I've come to realize there are serious downsides to letting things run their course too. Some changes are very hard to roll back (famous 'cat's out of the bag') just taking a lot of time to reverse if ever. For example, once there is a long term contractual agreement, if one parties decides to roll back they may just not be able to until the contract expires (like renting land; or worse, selling). A change in software systems for example that need backward compatibility can be quite difficult in technical and nontechnical ways.
I think people need to also keep some sympathy for the protests and let people protest more. I'm leaning more toward: if in doubt, provide visibility to a cause (even if not full support). It's okay to save yourself some energy (in particular for the most important causes). Some things might have to run their course for people to understand they were valuable, and we will probably have to eat some frogs as a consequence. Don't lose you sanity ;) (As the saying goes, "Don't you dare go hollow.")
This is a useless argument since there is no way to measure what case is this and what is not.
You can say "Classic slippery slope fallacy." to whatever seems like that to you.
This is an antipattern to scientific thinking as you can frame something x and then say all x are like this, look I created this framework to think about x. But in reality there is no empirical basis for this thought. And it serves no purpose other than doing more argument or winning arguments.
In the end what you wrote equates to "I don't think all of this will happen".
Chaning many possibilities makes the outcome less and less likely obviously.
Also the same principle applies to most religions I know of, for example:
- Assume there is God
- Assume it did create universe.
- Assume x
...
Then this also fits the same pattern and be called the "x fallacy" but it is useless to create an argument like this. This is useless mainly because this thinking pattern is ubiquitous in any world view.
More productive discussion might be to pick some steps in the theory they chained together and argue on that imo.
I don't know which timeline you live in, but in mine I've stopped counting how many slippery slopes ended up exactly where the critics said they would.
Is it a fallacy if you've said before that Google is aiming to create a walled garden, Google itself has already started saying it wants a walled garden and they've already implemented several such steps?
It all depends on how you define malware. If malware is software doing something that is contrary to the user's interests, then for many users it is indeed malware.
>this malevolent process has exactly one goal: to block you from running software by developers who haven’t been approved centrally by Google.
This claim is made by FDroid with no evidence. They make this scary claim which goes against everything Google has claimed so far. They are a biased party, and I can't trust their opinion. I would appreciate if they shared a more in depth investigation or a way to verify there big claim.
Trust is not binary; we can process data with a level of confidence. We do not need either Google or F-Droid to be sanctified before we evaluate their claims.
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.
>If you are running Android 8 or higher, a virus has been installed on your device and is silently awaiting remote activation.
I have such a phone and the "virus" has not been installed to it. There is no evidence behind this claim.
>with as many as 4 billion Android handsets and tablets estimated to have already been contaminated
This is misleading wording. It's just as true to say that as many as 1 trillion devices have been contaminated. It is state an impossible upper bound to drum up fear.
>this trojan horse runs surreptitiously in the background as a system service with full root privileges
Services in Android do not run with root privileges. Android practices the principal of least privilege where individual permissions are granted instead of giving it blanket access to everything.
>The service cannot be blocked, disabled, or removed.
This is unlikely to be true. You can most likely use "am" to disable it.
>In fact, Play Protect is itself the vector through which this virus is transmitted and installed.
This is probably false. Realistically it's going to be transmitted via the google play store like all other play service components.
>There are many things we don’t know about what to expect on September 30
>What will happen if I try to install or launch the F-Droid app?
Once active if FDroid not verified the user has to use adb or have enabled sideloading by unverified developers. If it's already installed the user can launch it.
>What will happen to all the apps I’ve installed through F-Droid? Will they be disabled? Deleted?
Nothing will happen to them.
>If apps that I rely on are suddenly disappeared, what happens to the data they contain? Can I still retrieve it?
Nothing will happen. But if Play Protect were to flag malware it manually asks you if you want to delete the app. If you delete the app the data will be lost.
If you can just disable it with the activity manager or similar, I don't think Google would provide another workaround with a wait time and everything - and that only after a lot of public pressure. It's claimed to be a security feature against scams, and scammers can theoretically let you open up an adb shell and run an am command, so that would negate the safety. (That this never happens in practice imo demonstrates that it's just about ecosystem control and not actually for user safety.)
I agree on the root thing though. I don't have a device here that has this service running so I can't check the process permissions for myself, but it seems extremely doubtful that it runs as uid 0. Fdroid could have dumbed the technical permission level down in more accurate way
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?
>and scammers can theoretically let you open up an adb shell and run an am command
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.
- 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 most stable/bug-free in this list.
- Ubuntu Touch: fully open source and community driven, it uses snap packages for security, you might be able to run android apps. Last time I run it also seemed fairly stable/bug-free.
- PureOS: fully open source and privacy focused. I think it's the only one that, released with the Librem 5, can avoid using proprietary blobs for interfacing with the hardware. Seems less stable than SailfishOS and Ubuntu Touch. You would need to buy a fairly expensive-but-old phone(librem 5) to run it.
- PostmarketOS: fully open source, focused on being lightweight and revive old phones, has a huge amount of phones it has been tested on, is based on Alpine.
- Mobian: mobile version of Debian, it's fairly new on this list.
There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.
These operating systems aren't compatible with most of the apps and services people want to use. It's going to become much worse. The compatibility layers several provide have extremely poor compatibility combined with disabling the Android security model and app sandbox. Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more.
Aside from that, many people care about privacy and security. Each of those operating systems is far less private and drastically less secure than the Android Open Source Project. None has a truly complete and working app sandbox or permission model. None uses modern exploit protections. None has serious hardware-based encryption features needed to protect against data extraction. They're not serious alternatives to an iPhone from a privacy and security perspective as an AOSP-based OS on decent hardware can be.
> but in case we don't manage to push back on this
It's a warning that's being added to Google Mobile Services operating systems. It doesn't negatively impact other operating systems based on the Android Open Source Project.
> various actual linux OSes for mobile
Linux doesn't mean GNU/Linux or systemd/Linux. It doesn't at all imply using glibc, systemd, GNU coreutils, Bash, GNOME, etc. Distributions using different userspace components including several of the ones you've listed are still Linux Android-based operating systems including AOSP and GrapheneOS are Linux distributions. Alpine doesn't use glibc and SailfishOS has a lot of their own mix of open and closed source software. Using a typical desktop Linux userspace stack isn't what makes it Linux and there's also not a lot of consistency in what's used on desktops regardless. A Linux distribution not using musl, glibc, GNU coreutils, etc. is still Linux.
> There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.
AOSP-based mobile operating systems are Linux distributions.
Exactly this.
If I can't run WeChat, Venmo, my brokerage app, WhatsApp, etc. it's a non-starter for me. I might as well not have a phone, because these apps are pretty much the only reason I carry around a phone.
Being isolated a little bit more from the kernal offers an illusion of privacy meanwhile where you are, what you have installed, your photos and friends are available to other apps at a much higher level. I understand being able to slow down a nation state actor is important but most privacy concerns for average people happen at the OS level not the kernel.
Personally, I do not use Android apps on the Librem 5, but Waydroid is available in the PureOS repository. Waydroid is a container-based approach to boot a full Android system on regular GNU/Linux systems running Wayland based desktop environments (like PureOS).
PureOS also provides convergence via Phosh. Convergence means here that the same app can be used on a phone and on a big screen, the GUI adjusts to the available screen size.
Phosh aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux. Phosh was originally initiated by developers from Purism for the Librem 5 phone but is nowadays used on many different devices covering smartphones, tablets and convertibles. It has even been seen on laptops.
No, it's only a partially working form of Android with the privacy/security model largely disabled and poor app compatibility. Waydroid is based on an ancient release of Android and disables the SELinux-based privacy/security model. It doesn't contain apps from each other and has far less protection for the Linux kernel from the apps. It has poor app compatibility and isn't a good approach to running Android in another OS. ChromeOS made a proper better Android container not losing the privacy/security model but migrated to using hardware accelerated virtual machines. It makes a lot more sense to use a VM since current era smartphone hardware fully supports it.
> PureOS also provides convergence via Phosh. Convergence means here that the same app can be used on a phone and on a big screen, the GUI adjusts to the available screen size.
Android Open Source Project has a desktop mode. It has a hardware-based virtualization layer for running desktop Linux applications too including GPU acceleration support.
> Phosh aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux.
Android runs fine on mainline Linux. It doesn't require special kernels. That's tied to specific hardware rather than Android.
PureOS has far worse privacy and drastically worse security compared to iOS or AOSP. It's bringing the traditional atrocious privacy and security of desktops to mobile. Librem 5 also combines that with extraordinarily insecure hardware missing basic firmware updates and security protections. As a whole, these make it drastically easier to exploit devices. That includes going back to disk encryption which doesn't work for the average user due to them not using a strong passphrase and not protecting against data extraction with physical access unless the device is turned off.
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.
With an increase in mobile Linux (e.g. Mobian and others), they can and will get better. Customers and developers choice and freedom are being nullified, because there are few other options. That has to change.
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.
They're also no match for the privacy or security of iOS or AOSP. They're bringing the lack of privacy/security model and protections on desktop operating systems and hardware to mobile. It's a massive regression for privacy and security despite being marketed in the opposite way.
Well, IMHO Gnome has worse UX than other linux environments like KDE, Niri witn Dank Materials Shell, etc. That is obviously a matter of opinion, but I don't think you necessarily need a large budget to get decent UX for an open source project.
But I prefer this to the feeling that I'm being limited on what I can do on Android/Apple, and the worry of being in a duopoly that allows the companies to worsen their products without ever fearing competition(as far as they do it in small chunks).
Also the bank should not require apps (instead they can offer hardware key support or desktop apps) and in fact some - at least in Germany - offer a different authentication possibility. Also the app for the German ID is published on fdroid and does not rely on Google services.
I'm confident this is a very common experience worldwide, be it with gov IDs or banks.
To be honest, life without a smartphone was increasingly becoming a PITA.
For example, Ryanair doesn't accept printed tickets anymore.
A few clubs in Berlin (Tresor, Ohm, Oxi) have recently replaced their cloakroom by automated lockers that require a smartphone to operate.
I've encountered a few gyms (2 in Spain, 1 in USA) that use live-updated QR codes to enter the gym.
I did a project in the US and the client's office required a smartphone to open the door.
In Spain it's common since the pandemic to have restaurants that only offer the menu as QR code.
In fact, the pandemic was rough, as you had this system where you had to register with a QR code in most places. In many places they had a paper-registry that I could use, but often I would have to end up just using a friend's phone.
Plus all 4G dumbphones are crap compared to older 2G models. The few that exist are built really bad, designed for old people, lack features like T9. 2G is out already in great parts of the world.
To be honest, it saddens me deeply that the only way to live in society today involves carrying an internet-connected computer in your pocket. But it was just too much of burden... With GrapeheneOS the experience still feels somewhat acceptable and I get a somewhat similar feeling of control to what I get using NixOS on my laptop. But still...
Additionally, there are many sports and music venues where i live that require smartphone apps for ticketing.
Giving up my favorite forms of entertainment and transport isn't really reasonable imo
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.
Ride hail app? Transit fare app? Government ID app? Airline app? Maybe you don't need them yet, but the best way to model this future is to consider what you'd do if you didn't have a phone at all, and the amount of friction this will generate as the expectations are only entrenched and expanded.
I'm glad people are saying no. It's good to do it as long as we can. But the final outcome seems inevitable now and to me it feels very close.
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)?
This makes emulation basically impossible.
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.
I do not have any bank apps on my phone (it is not even connected to the Internet) and I have no problem.
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.
I blame it on the fact that the US doesn't have a free electronic bank transfer system like the rest of the developed world.
These might not be very common, but they're still not really rare in society either.
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.
They likely wont specify 100k people or 10% of population or whatever email/petition but it at least records the requirement that other OSes exist and requires a process to support
But banking apps are a problem.
It's not even about the main online banking (you can use a web portal) or storing a EC digitally in you phone (convenient but really unneeded).
The problem is dump, misguided 2FA apps. E.g. credit card 2FA which already mostly required Android/iOS to work or even online banking login 2FA, transaction 2FA etc. with same requirement.
Currently for the later I can still use other methods but for a huge amount of Banks where I live you can't use a credit card (reliably) without Android or iOS as "carrier" for an 2FA app.
HN commenters will not let it go
Most HN readers have multiple computers, including multiple phones
There is no requirement that one has to run a closed-source banking or government ID app on the same phone as open-source apps, e.g., apps from F-Droid
And it ignores countless people who do not and will never use banking or government ID apps
I tested a banking app for depositing a paper cheque and it was incredibly convenient. At the same time, the app tried to make a plain, unencrypted HTTP connection to www.google.com
I blocked these connection attempts and the app still worked, with plenty of phoney error warnings. I would not be comfortable leaving one of these apps installed on a phone that's charged, powered on and has a cinnection to the internet
Every user is different but it makes no sense to argue on HN of all places that these closed-source banking apps are essential for everyone. Many HN users are never going to use these apps, and rightfully so
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
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.
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.
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.
That's debian based with gnome and seems to be built by capable people. Also, it can run android apps.
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 phone maker, while others are community ports. Even if community ports, they all seem to have high hardware support, and is all very clearly documented.
- https://puri.sm/products/librem-5 / https://pureos.net
They focus just on the Librem 5, and not everything is fully working but as I said they prioritised privacy and FOSS. The phone is old but the OS is still in active development.
- https://postmarketos.org - https://wiki.postmarketos.org/wiki/Devices
They focus on supporting as many devices as possible, currently they don't have "main" devices they support, but they plan to. They too have a very clear documentation on features available for each device.
- https://mobian.org - https://wiki.debian.org/Mobian/Devices
They target devices made with the intent of running linux, but also have a few ports to android devices.
---
You'll notice that there are a few devices that are more "linux-friendly" and that are supported by many of these OSes. Phones from Pinephone and Fairphone being the main ones.
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...
I bought a Librem 5 a few months ago, so I'm sure on that one.
The Fairphone 5 is around 3 years old, it doesn't seem to be listed in the official store, but they are big on reusing so I think there should be at least a few second-hand ones being sold(I found some on ebay, and some on their forum). I can also see it listed for sale on amazon uk.
The pinephone is another one very old, they seem to have the "basic edition" still avaliable, but it might be slow.
I also noticed SailfishOS is taking pre-orders for a new phone that will be released in october.
But I must admit a lot of the ones I listed might be too expensive if we consider how old they are
Someone needs to create a Linux based mobile OS foundation - Google's domination is contrary to many large companies interests, and if Meta and many other such companies were approached, they may well donate large sums of money in their own strategic interests.
Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
An old article [1] but:
> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices
So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
[1] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[2] https://arstechnica.com/tech-policy/2021/07/google-bought-of...
GrapheneOS doesn't license Google Mobile Services (GMS), doesn't include it in the OS and doesn't have Google certification. It isn't permitted by the Google Play Integrity API device and strong integrity levels because it doesn't have a GMS license. Google doesn't offer any way for GrapheneOS to license it.
We're legally allowed to provide compatibility with Google Play via our sandboxed Google Play compatibility layer. Similar to APK mirror sites, we're also allowed to mirror the freely available APKs.
We've put enormous time into developing sandboxed Google Play compatibility layer and there's ongoing work to continue resolving edge cases we haven't covered. If Google wanted Google Play to be used outside of stock operating systems licensing it, they could make it work as a set of regular sandboxed apps without us needing a compatibility layer. Our baseline compatibility layer isn't doing anything they couldn't do themselves by making them apps handle being portable to operating systems not deeply integrating it into the OS with highly privileged access.
maybe once that happens grapheneos will finally take anti-fingerprinting seriously.
No, and you also don't understand how the Play Integrity API is implemented.
Google has a bunch of monopolies tied to Android. Antitrust laws put limits on what they're allowed to do which Google has been egregiously violating for many years.
Google isn't legally allowed to pull a bait and switch with Android by changing it away from an open platform and open source project. They used Android being both of those things to build and expand monopolies in a bunch of areas. The way Google exerts control over OEM partners with Google Mobile Services licensing has already been found to be illegal in multiple countries and they're in the process of losing more court cases over it. South Korea found their terms to be highly illegal and Samsung is already largely free from their restrictions.
Play Integrity API enforces the Google Mobile Services licensing model. The licensing model and terms are highly illegal in countries with decent antitrust law. It has already been found to be illegal by the courts in multiple countries. EU and US have particularly strong laws where they're egregiously violating and that's going to have consequences.
Play Integrity API is primarily based on hardware attestation, which is not fingerprinting. The strong integrity level fully requires hardware attestation and services using it are migrating to enforcing that. Device integrity level requires hardware attestation for devices known to have a working implementation which is a major loophole but it's gradually being closed. Play Integrity API also has many software checks.
Play Integrity API software checks require having an immense amount of privileged access which means it's not very compatible with sandboxed Google Play without an immense amount of work which would achieve nothing. Tricking all the software checks won't make it start permitting GrapheneOS. It's not feasible to pretend the device is one without hardware attestation while avoiding it being detected that it's being faked. None of this can be feasibly bypassed in the long term without it repeatedly breaking and becoming increasingly impractical to bypass. Many apps already require hardware attestation via the strong integrity level and eventually Google will close the loopholes for the device integrity level.
> maybe once that happens grapheneos will finally take anti-fingerprinting seriously
It isn't fingerprinting and no amount of anti-fingerprinting will bypass it. Hardware attestation exists and it provides the device model and OS. It's also easy for apps to detect those in many ways. Apps can just look at their own memory and see the OS libraries loaded into them. The only way to pretend to be the stock OS even without hardware attestation would be making essentially no changes to anything since apps can look at a lot of OS libraries, etc.
Running apps in VM wouldn't solve anything either and will only work for apps which don't try to detect being in a VM and don't use hardware attestation or the Play Integrity API. We'll still need to support running apps on bare metal once we have VM isolation features since one of the main things apps doing these anti-tampering and attestation checks is trying to block is being run in a virtual environment.
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.
if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos. how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?
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.
both remote attestation packets and DRM license request responses contain a unique hardware identifier that can be extracted with knowledge of the right secret information.
in the case of attestation, privacy CA and the verifier must collude to do this (technically, you need the ephemeral key provisioning packet + attestation packet + secrets). blind signatures were proposed to make this impossible and REJECTED. using a proxy/VPN does not prevent having your unique hardware identifier be attributed to the attestation in this scenario. also note how when you attest to google both the CA and verifier are one and the same...
with DRM I'm not even aware of any effort to not directly expose the KeyBox public key to a license server, and ANY app can make use of DRM API. you do need the license server's private key to extract the identifier however.
Permit faking hardware attestation by providing a remote attestation provider device that runs stock Android and a corresponding app. When app on GrapheneOS asks to be attested, that request gets routed via the cloud to the stock Android remote device. People will have to buy 2 phones, one running GrapheneOS that they actually use, one that runs stock Android that they can lock up in a closet plugged into power.
>So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort.
What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
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.
GrapheneOS has an official partnership with Motorola Mobility which is improving their next generation devices to meet our requirements and helping us port GrapheneOS to those. GrapheneOS will be officially supported on those devices with Motorola Mobility providing us with the stripped down hardware support code we need to support their devices with proper firmware/driver/HAL updates.
A bunch of companies are already selling devices with GrapheneOS installed. Those companies can start buying the future Motorola devices supported by GrapheneOS and doing the same thing with those which they already do with Pixels. Motorola can also specifically sell devices to other companies to sell with GrapheneOS with official support from Motorola.
> prohibiting OEMs from making or partnering with "non Google approved" OSes
It has been challenged in court and ruled to be illegal in South Korea and elsewhere. Regardless, it's only an inconvenience and can be worked around. Even if Motorola can't sell devices with GrapheneOS in many countries themselves, those can still be sold by other companies and Motorola can sell devices to those companies at wholesale rates where they can match the price of the non-GrapheneOS devices. Other than Google, most OEMs aren't directly selling most of their devices anyway.
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.
Very little in GrapheneOS has gone back upstream post-Copperhead.
> Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, for Graphene.
What are you talking about? Google doesn't use hardened_malloc, and they literally invented MTE.
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.
Doesn't GrapheneOS supports only Google Pixel smartphones now? For most of the users, that would mean changing their phones beforehand. And if we're talking about common people (especially not in US), it's not even everyone who can afford that. Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
https://grapheneos.org/faq#future-devices
GrapheneOS has an official OEM partnership with Motorola Mobility and a subset of their next generation devices will be provided official support for GrapheneOS. They'll be providing us with a more minimal form of hardware support code close to the standard Qualcomm and other vendor code, so it will be cleaner than Pixels. Our partnership with Motorola is non-exclusive so we're free to support other devices with the help of other OEMs interested in meeting our requirements, but no other OEM is working with us yet.
We can't use devices with an end-of-life Linux kernel, no firmware updates, no driver/HAL updates and no support for important hardware-based security features we use. Several devices of a lot of the way towards providing what we need and several next generation Motorola devices will provide it. Other OEMs can do the same.
Most people don't have a device permitting using another OS at all or without crippling functionality including security. They need to buy a device to use another OS as a production quality daily driver. The vast majority of GrapheneOS users bought devices to use GrapheneOS rather than using GrapheneOS because it was available for a device they bought without considering it.
We don't want people to buy devices which will stop getting privacy/security patches for the firmware, kernel, drivers and HALs after 2-3 years and are missing important security protections. If we support a device then people are going to buy it to use GrapheneOS. Few of the people who end up using it are going to be people who already had it.
We don't want to have a watered down form of GrapheneOS without the core protections including what we build with hardware memory tagging. Older devices which we discourage buying not providing all the current requirements is much different from adding new devices without those. Our recommended devices (Pixel 8 and later) provide all of the current requirements and we strongly discourage buying older devices without enough support time remaining or the current protections.
We have a serious OEM partnership because we stand by our requirements and haven't watered down GrapheneOS. An OEM working with us to improve their devices to meet our requirements and helping port GrapheneOS to those with full functionality is only possible because we don't poorly support anything able to run another OS.
GrapheneOS is open source and others are free to make incomplete ports to other devices under a different name. Many individuals and companies have done this and it hasn't gained any significant interested. It doesn't provide what GrapheneOS does and the expectations of our audience are much higher. Our audience doesn't want a device with 2-3 years of delayed security patches for the firmware, kernel, drivers and HALs follow by end-of-life.
If you have GrapheneOS, you have the best mobile security you can get, period.
https://www.androidauthority.com/grapheneos-motorola-partner...
That would all be worth it, but it's been a few years and Google did all the shitty stuff I was protesting anyways and Apple is getting worse.
I'm hoping we get those moto phones with graphene pre installed so I can actually send the right market signal. But what's fucked up these days is you can't send the right market signal. Meanwhile I talk about fixing shit at work and my coworkers ask "what's the value" or say "there probably isn't any money in doing that". Even for problems they are one liner fixes and that they agree we spent more time arguing over than it would be to fix it. I don't think it's a top down problem, it's a bottom up. Those are much harder to solve
For good reasons. Most other devices arent secure enough to guarantee privacy. Especially not if loaded with a custom operating system (most devices don't allow to verify the boot chain with a custom OS)
> And if we're talking about common people (especially not in US), it's not even everyone who can afford that.
You can get a new Pixel 9a here in europe for around 350€ and it will be supported at least until April 2032
> Moreover, in my opinion, by buying Google phones you're feeding Google, and I, personally, would like to avoid that.
Google phones are surprisingly open and work well. Google takes a pro-user stance here that is extremely rare in the ecosystem, so why not support this product?
It would theoretically be possible to port it to a newer kernel but that's not within the scope of LineageOS. It doesn't do that so there aren't Linux kernel updates since the kernel branch has been end-of-life for years already. It would also theoretically be possible to rewrite all the userspace drivers and HALs, but it's not being done. The firmware is a different story since it's usually signed and requires vendor support. It's important too since it's exposed to remote attacks via cellular, Wi-Fi, Bluetooth, NFC, GPU (web browsers, etc.) and more.
Your very rigid view of the world is so distorted to the point of being absurd. You know damn well that the vast, vast majority of spying on Android is done in userspace.
A good OS that allows you to remove permissions from apps and further isolate things does a lot for privacy.
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.
Frankly, that kind of rigid attitude/black and white thinking might be why you find it so hard to collaborate with upstreams.
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.
Qualcomm offers up to 8 years of updates from platform launch. Getting around 7 years of updates requires OEMs to use the latest and great platform combined with paying Qualcomm a lot of money for long term support. It may cost a million dollars or more for each year of support. OEMs also need similar support for other components but that mostly means choosing decent components.
Providing proper updates has a cost most OEMs haven't been willing to pay. Pixels and Samsung flagships have been the exceptions. Samsung doesn't properly update most devices, only flagships, and it's still worse than Pixels in important ways. Samsung has also been closest to having all the hardware-based security features we need but doesn't let us use a lot of those due to crippling devices if they're ever unlocked.
Our partnership with Motorola Mobility partly involves them improving their devices to meet all of our requirements which was already largely happening. It also requires porting GrapheneOS to their devices and fully supporting Snapdragon again including having hardware memory tagging support on it for the first time. No one is currently using hardware memory tagging in production on Snapdragon let alone for the entire kernel and userspace as we do so it's going to be a lot of work. Motorola is going to be helping with all of this. They're also going to provide us more minimal hardware support code without unnecessary changes not needed for AOSP / GrapheneOS. A bunch of GrapheneOS features need to be ported and the device support code needs to be made compatible with our changes too including but not limited to fixing memory corruption bugs.
GrapheneOS closely follows along with Android releases, Linux kernel LTS revisions and driver/firmware updates. It had an experimental release based an Android 17 after only 2 days of it being released earlier this month. It quickly made it through our testing process with many regressions resolved to our Stable channel. This is part of what makes it GrapheneOS and an incomplete port to another device without the same updates wouldn't be GrapheneOS.
GrapheneOS is open source. People can make an incomplete port of GrapheneOS to other devices using their own project name. It's not a port of GrapheneOS to another device without having all the features and updates.
We phase in new hardware requirements for standard security features and the older generation devices without those are eventually gone. Adding a new device without hardware memory tagging would be far different than still supporting 6th/7th gen Pixels without it since we strongly recommend against buying those devices anymore and they're going to end up end-of-life.
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.
In 2027, you will be able to use the Motorola flagships to run GrapheneOS.
Grapheneos is still based on Android.
Because they will pull the rug here one day too. Why on earth should we trust them to keep this approach to their hardware?
GrapheneOS has an official OEM partnership with Motorola Mobility and a subset of their next generation devices will be provided official support for GrapheneOS. They'll be providing us with a more minimal form of hardware support code close to the standard Qualcomm and other vendor code, so it will be cleaner than Pixels. Our partnership with Motorola is non-exclusive so we're free to support other devices with the help of other OEMs interested in meeting our requirements, but no other OEM is working with us yet.
We can't use devices with an end-of-life Linux kernel, no firmware updates, no driver/HAL updates and no support for important hardware-based security features we use. Several devices of a lot of the way towards providing what we need and several next generation Motorola devices will provide it. Other OEMs can do the same.
To avoid writing the same thing a 2nd time without forcing people to use a link and lose their place where they were reading.
> barely answers the question
We fully answered the question by explaining why we currently have to use Pixels and why we won't depend on Pixels anymore in less than a year. You're ignoring our explanation of our Motorola Mobility partnership. It explains why we need the partnership instead of adding support for devices without it too.
> But you answered with your text about how other smartphones don't have important "hardware-based security features".
No, we explained most devices don't even allow another OS and many of the ones which do cripple functionality including security so we can't support those. We also explained we need firmware, kernel, driver and HAL updates for a reasonable amount of time. We need the hardware-based security features we use to implement the core protections provided against attacks. It wouldn't be GrapheneOS without solid protection against remote attacks, apps and data extraction. We linked to https://grapheneos.org/faq#future-devices which lists out what we need. It's strange to ignore updates or put scare quotes around something we provided a detailed explanation for in the linked content.
After all, it might rain tomorrow - but you should still go outside today.
Convincing developers, especially bank and gov apps, is near impossible and won't scale well. Going after Alphabet for not meeting DMA obligations seems the easier path. Might not go anywhere but worth a shot.
1. Provide or find pro bono legal resources deeply familiar with EU DMA and similar antitrust regulations, willing to proof-check and improve this report, and perhaps advise on better channels to submit it.
2. Locate more affected end-users, including applicable members of the GrapheneOS Foundation and developers behind other distributions, make them aware of these efforts so that hopefully we submit a joint complaint. (Might get more traction, though AFAICT reporting is limited to EU citizens).
Happy to fork this into its own repository if it helps with collaboration.
A heads-up: the FSFE has already submitted a case for device neutrality regarding both, the ability to completely uninstall AI features and the unlimited interoperability decoupled from ADV: https://fsfe.org/news/2026/news-20260615-01.en.html
“Interoperability must be decoupled from developer verification procedures. We need clear, precise, and inclusive rules to prevent circumvention by gatekeepers and to ensure that interoperability becomes a concrete reality in practice” states Lucas Lasota, FSFE Legal Programme Manager
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
AFAIK they make use of this: https://a-sit-plus.github.io/warden-supreme/integration/supr...
[1] https://privsec.dev/posts/android/banking-applications-compa...
But just the thought of the potential to be completely locked out of everything from banks to online payments, logins to the public health system, tax filings (and basically all public sector services) just at the whim of Google or Apple's automated algorithms misunderstanding some random account activity, is a thought that should make everyone (and especially those in countries dependent on systems like BankID) afraid and demand at minimum:
Rights to:
- Due Process
- Accountability from Google & Apple and fines for when they do wrong
- Multiple warnings (with a right to know what you're being accused of) before being locked out
- Well-functioning complaint procedures with strict time frames
- Make the mere concept of banning users "for life" illegal
...from Google and Apple (and strict fines for them not adhering to them). Feel free to add more to the list.
Else we as a society can't depend on a smartphone as the main key to our lives anymore.
source: I eventually got bankid on the phone in late 2025
AOSP is a Linux-based mobile OS. It runs fine on top of standard Linux kernels without downstream changes. Getting rid of the need for closed source userspace drivers for components like a modern Mali GPU can be done with AOSP and will benefit the most people that way. AOSP if many companies and others band together to do it. It could also happen due to government intervention due to Google's antitrust law violations, but that could be done poorly in a way that harms open source.
Billions are spend right now to make sure the glasses also run Android or iOS. So far, Google, Samsung, Magic Leap, RealWear and Vuzix are working with/on Android XR, and obliviously Apple is working on AR/VR iOS.
Meta and a couple of smaller startups are doing something in-house, but I don't give them much chances to get an ecosystem going.
Rolling the dice on a new technology could wind up being much more favorable.
(For those who haven't been following along: this whole affair started with phishing. People were social-engineered into installing an app and a little later their bank accounts were empty. A big issue in various poor countries.)
This is also the argument they use to try to convince app vendors to add their keys to the allowlist, because the app makers can trust that their DRM will be active (if Netflix sets a "no screen recording" flag, you the user cannot circumvent it by e.g. reading /dev/fb0). It should have broader compatibility than other FOSS Android builds (when running the officially signed version of course, you can't compile it yourself and expect such apps to run there)
One of the core tenets of truly free software is that I as user must be able to run, access, edit, and view everything.
That's such a fun statement.
Any security measures taken always remove agency from one person and give it to another.
iOS takes my control away, and in turn gives that control to Apple. GrapheneOS takes my control away and gives that to the GrapheneOS developers.
The "security" you're talking about doesn't prevent certain data from being accessed, it just changes who controls the access.
If the user cannot be trusted with their own data, then there is no solution anyway. They'll just tell their private data to a scammer on the phone instead.
There is no solution against a user that wants to give their own data away, but if you try to prevent that, the only thing you'll accomplish is destroying general purpose computing.
That'd still allow you to free your data.
Ideally though the native filemanager should just have a sudo mode that can be entered to access everything, if desired.
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.
The user must be the administrator of their own device. Whether that's a laptop, desktop, PDA, mp3-player, smartphone, tablet, cyberdeck, netbook, or any other kind of computing device.
The user must be able to overrule any and all decisions. That's the definition of ownership.
Like, this was the reason why GNU was founded, and before that was the plot of the movie TRON.
Its really funny because Tron, or at least Tron Legacy, is a great example of why godhood is dangerous and why a user and a program having root access is catastrophic.
> 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.
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.
Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
The randomness of an app is irrelevant and apps need to jump through significantly less loops to obtain root access without your input. And even if they didnt do that, and you permitted root instead, the app can lie about you revoking it later in either case.
This is blind ideology over safety and real ownership. Root is a hacky shortcut for proper functionality, and is not a prerequisite to ownership in the slightest.
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.
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.
Awesome, so you're advising against installing GrapheneOS for anyone that wants control over their own data.
Sorry for twisting the words slightly, but that's the essence of the issue here, isn't it?
> Its not advisable to run anything as root, at all. Or expose access to it in any form.
And then you advise for exposing access to it in pretty much the same form I asked for before.
It'd be funny if it wasn't so exhausting.
Regarding the security model: So adjust the security model.
Any access that an app can have, should also be available to the user. Importantly, they should be able to access and modify any data.
The system documents/files app already has special permissions for that, there's no reason why it shouldn't have access to all files (accessible through the same unlock system as e.g. the security settings)
To be clear, I am NOT advising root access. I am not contradicting myself. I am telling you it is dangerous but still telling you how it can be done in a less terrible way. To withhold that info would be senseless gatekeeping. GrapheneOS supports being built as a userdebug image but that will not stop them from telling you how bad an idea it is to use it on a production device.
GrapheneOS will not be rolling back aspects of the security model. That would be a massive step backwards for privacy and security.
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.
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.
You use operating systems that have significantly worse security than GOS, iOS and even stock Android as your examples?
Also you literally are the owner with GrapheneOS, lacking security is not "full ownership." You can create your own build of GOS, you can modify it ahead of time, you can literally see all of the source code it's running.
Claiming GOS isn't true ownership is like complaining that you can't change your car's wheel alignment while driving it and saying it means you don't truly own your car.
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.
The vast majority of scams literally work by them asking their victims to buy cryptocurrency or gift cards directly. Malware is exceedingly rare.
You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
Modern society has created far too many situations where people need to react without being able to think through the consequences.
The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
Source? This article suggests otherwise: https://www.economist.com/interactive/asia/2026/04/10/scam-i...
Moreover it seems to be limited to south east asia for now. Just because you're in the US and all the scams you're getting is cold calls from microsoft tech support, doesn't mean scams with smartphone malware doesn't exist.
>You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
>The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
In other words, "if we had world peace and everyone could hold hands and sing kumbaya, then we won't have to worry about scams!"
This particular attack requires getting users to sideload apps that would be rejected by the play store, and most users don't have developer mode enabled. Therefore, the cost of persuading someone to enable developer mode matters. If the procedure to enable developer mode changes from "open settings, scroll down, tap, scroll down, tap seven times" to include e.g. a 96-hour wait for developer mode to be enabled, then the cost of the attack rises by whatever it costs to stay in close contact with the victim for 96 hours, close enough to react if the victim comes close to realising the truth.
This isn't a guarantee. You can still get phished even if the phisher has to spend 96 hours in intensive contact with you. Some victims are worth that effort, maybe you are, and maybe the phisher made a mistake and puts in the effort to phish you based on the mistaken assumption that you're a millionaire.
There are also other things like that. If Google can ban the keylogger you use quicker than you can deploy new builds, for example. Still no guarantee.
Yes. For example if you install an apk from an unknown source (like a random website via browser or messenger) it will warn you what you are about to do and what effects that has.
You don't need to block stupid behavior. Just make sure users are well aware of their actions as long as they actually read warnings.
also, 'rooted' means you have root access, not that you run everything as root.
I bought a /e/os Fairphone instead.
* (March 2026) Motorola announces a partnership with GrapheneOS Foundation - https://motorolanews.com/motorola-three-new-b2b-solutions-at...
I'm actually curious if there's something I don't know about /e/
AOSP is open source and written by Google. If you strictly don't want Google, you don't use Android. But IMO it's a shame because AOSP is actually good.
You could argue that you don't want to buy a Pixel because that would be giving money to Google, but not giving money to Google does not help the good alternatives, does it? IMO, helping the good alternatives means supporting GrapheneOS. The bigger GrapheneOS gets, the more likely it is that they get to work with major manufacturers (they already work with Motorola, which is great).
If you buy a Fairphone and run LineageOS, you are still running Google code (AOSP) and you support Fairphone who do not seem to care so much about security (otherwise they would meet the requirements of GrapheneOS).
Why do you choose to die on that hill? It's ridiculous!
Do you get manufacturer updates? My experience with /e/OS was that the Stock Android was up-to-date but /e/OS was 4 years behind, on a Fairphone.
> for reasons I do not understand, Graphene OS is very closely tied with Google hardware
One of the requirements is precisely to be able to add custom keys and relock the bootloader, in order to keep the Android security model. Most other phones don't allow that.
e.g. first one in the list:
> Support for using alternate operating systems including full hardware security functionality
GrapheneOS wants users to lock the bootloader (≈enable Secure Boot) after install by providing user signing keys (avb_custom_key) -- that already seems to leave only Pixel, Nothing and Fairphone.
https://github.com/chenxiaolong/avbroot/issues/299
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.
That's debatable. /e/OS is mostly made of AOSP, which is made by Google.
> It is less secure than Graphene
Most definitely, yes
> but also leaks less data to advertising companies.
This is wrong. If you don't use microg on /e/OS or Play Services on GrapheneOS, then it's equivalent. If you use microg, it still contacts the Google servers even though it is an open source reverse-engineered implementation of Play Services. The added privacy there is to go through a proxy, which GrapheneOS offers.
I actually like it better to run sandboxed Play Services through the GrapheneOS proxy, because in my experience it works a lot better than microg.
Really, the only reason to use LineageOS or /e/OS (which are interesting project, really) is that you cannot run GrapheneOS on your phone. If you have the possibility to use GrapheneOS, there is no good reason not to do it.
Your phone is running proprietary Google DroidGuard blobs in a privileged process every time an app initiates a Play Integrity request.
If you install some Google apps like Google Maps, they are run with more privileges than other apps (their microG fork gives apps elevated privileges when they match certain Google signing key fingerprints).
Also, your device is running a firmware bundle provided by Fairphone's Chinese ODM, including TCL image processing blobs. Your phone will soon run an ancient kernel and firmware tree with many known critical CVEs.
But this all doesn't matter anyway, because security hardening is only for spies and pedophiles according to the CEO of Murena (the company that makes /e/OS).
Confirmed, he says it in video: https://x.com/GrapheneOS/status/2040887784253141142
So, Android?
Which supports only Pixel devices.
I never treat my (Android) phone as secure anyway.
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.
I use a Samsung too. The bloat, dark patterns and enshitification with every update are even worse.
Long term I would probably have more hopes in https://postmarketos.org/
But yeah, vendors maintaining their drivers upstream in FOSS projects would obviously make it easer
With such an article, many (including perhaps google) get the ammo to disregard what fdroid says, by branding them as childish/not to be taken seriously. for eg: no reputable news org is going to post this.
PS: https://keepandroidopen.org/ is better done.
If we ask their fine search engine, the AI helpfully explains malware to be software designed to gain unauthorized access to disrupt, extort payments and/or hijack devices.
If you still think the shoe doesn't fit, imagine what would happen if one managed to create an app with the same capabilities. Google would remove it immediately for being malware. Obvious malware.
but I can totally see Google banning developers and removing their apps for political reasons, where some lobbying group bombs them with emails
because with this they're explicitly saying they're now choosing who gets to be in or out, there's no way for them to say we can't do anything about it
I do think this would improve security, but I also think it's sort of a Trojan horse to lock down the ecosystem
https://www.reuters.com/world/europe/kremlin-demands-explana...
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.
None of the other platform vendors with totally closed platforms are paying out anything.
So with even a room temperature business IQ, it's pretty clear that closed platforms are the best way to do business, and court rulings in both the US and EU have affirmed this multiple times over the last decade.
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.
all OSes have malware level capabilities. it's literally the definition of an OS
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.
You can only run LineageOS on smartphones that allow unlocking the bootloader (which is more and more rare), and properly release the kernel source-code (many still don't, especially low-end MTK-based phones...)
Maybe a case for the EU? I mean, they like creating laws limiting the power of big tech. Maybe there should be a law that requires all services that are used by public institutions and commercial transaction providers to be transparent to the public and therefore open source. And as a platform provider, they should be required to offer APIs to let users install alternative implementations.
Might require some fine-tuning, but you get the idea.
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
I would wholeheartedly recommend going for a Pixel with GrapheneOS. I have been an /e/OS user on a Fairphone for 5 years before reading a lot about GrapheneOS and switching to GrapheneOS. It's honestly so much better!
If you go from iPhone to GrapheneOS, you get better security. If you go from iPhone to anything else, you get worse (to extremely worse) security.
Google is Trojans all the way down. What is the true intent of almost every Google product? Data harvesting.
Every single product is spyware of some kind. They've even managed trojanize TVs by subsidising manufactuers to ship their spyware.
[1] https://en.wikipedia.org/wiki/Trojan_horse_(computing)
Android making another step in this direction is bad. But, let's not kid ourselves: we are neck deep in this cyberpunk serfdom, and have been for decades. If we were to get this Android win, it would be only a small win. I'm saying this not to be defeatist, but to remind us of the bigger fight.
How does this feudal goliath meet its end? When is enough enough?
all it takes is one guy who gets too mad for some reason
and it's gonna be a lot more costly for you to do anything about it vs. that guy who gets to be completely anonymous about it
But yeah, you could have a loony turn up.
They can sue you and Google will give your address to the court, clearly. But swat? Send packages? How?
I can see why your address is shown if you offer something for sale. Ads, that puzzles me.
I can see?
FairCode B.V. marcel+play@faircode.eu <redacted>
Anyway, ads are just a sidechannel for purchase. There is a product advertised, someone buys it and developer gets the cut from the seller of the product. This is how ads work.
With that policy, Google encourages stalkers and put developers in danger.
I would have been fine just preventing Californians from downloading my app, but that wasn't an option so I just let my app die.
There is a clear legal asymmetry where allowing competitors on your platform makes you liable if they complain, but blocking out everyone except for yourself is a totally ok and legally rosy way to do business.
https://www.eu-digital-markets-act.com/Digital_Markets_Act_A...
It remains to be seen whether the EU decides that this measure is strictly necessary, proportionate and duly justified. They sometimes do the right thing but I'm not getting my hopes up.
HNers (especially Americans) are super naive and think the EU is some bastion of freedom. no. it just wants to be a huge nanny state but in a wholesome way, where you can do whatever you want as long as it's approved
We've accepted that OS vendors can do this for decades. I think that was our mistake: relying on Google as the only available vendor. We can't make a law that punishes Google for having been open all these years. Yes, of course I (like any 'HN' hacker, I'd think) would be in favor of forcing Apple to be open as well, but then it seems that the powers that currently run the EU (and a lot of voters) kinda likes their remote DRM attestation for this digital identification project that you'll soon need for anything not suitable for toddlers and not reachable via a darkweb
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)
But then, Librem 5 Phone was just failed few years ago, telling the story that people who care about their rights are still sensitive to how much they would pay (which is a form of rights too).
Also but, there is the thing, making a phone is not easy. If you reach deep enough, you'll eventually reach the layer where you realize how solid the monopolization has become. The global telecom standards if you read them is in the hands of few companies, Boardcom, Motorola, Huawei, Nokia and such. They'll control whether or not your phone can access the network. Then there's telecom companies who runs the network, and they might have to approve your device/modem as well since they got their channel allocation from the government.
It's not easy, and it's not just the software problem.
Oh and yes, we also have the software problem. Linux, if you want to go that route, cannot be used as a mobile OS, as least not for the public, because the average people don't know how to properly secure their system, and Linux is not a restrictive-by-default system. It will be a malware nightmare if you ship Linux on a phone as is.
The best hope for now I think is for geek vendors to make more mobile/4/5G enabled Fairphone or uConsole-like product to the enthusiast market, and then you can load whatever OS on it as you want.
That's the same reason why desktop computer has so many malwares, that's why phones now has permission systems to restrict what an app can do on it.
If you want to create a system for everyone, including your 60 years old mom and her mom, you need similar of not better permission systems. Linux currently don't have that, and DON'T except an old fashion car mechanic will delicately configure AppArmor etc with his oily fingers in the middle of fixing a client's car.
1. People are conditioned to ignore warnings. There are way too many benign warnings in the world; you can't read them all.
2. Even when people wouldn't ignore them, in cases where they are being tricked by scammers it's easy for the scammer to talk people into accepting them.
3. Those sorts of warnings aren't actionable. You're installing a new app. It appears legit. You want to use it. You get a warning like "this app hasn't been verified; it might be malware!". What can you do with the information? Absolutely nothing. 99.9999% of users have zero way of doing any deeper check to see whether it actually is malware. Their only options are to give up and go home, or just hope that the warning is wrong. Even I - a highly technical user - get zero value from things like Windows' smart screen. "The app you're running hasn't been signed! It might be malware!". Err yeah sure. I'm not going to reverse engineer it to check am I?
I think their solution of allowing you to disable the restriction with a one-time one-day delay is actually a really reasonable solution. As long as they don't go further than that - the risk is that it is just a temporary placation and they'll ditch that option in a few years.
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.
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.
You can't possibly convince me that Google couldn't develop something like that if they wanted to.
How do you determine/enforce whether an app is a "payment app" without a centralized developer program? They don't require any special privileges. After all, most banking apps have web equivalents.
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.
Did it take the world by storm ? No.
But it exists, has users & is building the case (together with Sailfish OS and others) that having an abusive mobile OS duopoly is not the desirable state of matters.
Linux is a kernel. A Linux-based distribution decides what the defaults would be. Why, in your opinion, would a Linux distro targeting phone-ish ARM64 hardware be problematic? Why would it be a "malware nightmare"?
1) side loading, or however it's called, is used by less than 1-2% of global Android users (we can't be more than 50 million). Google made us a favor leaving it open after an only 24h delay. It could be much worse but now it's nothing in our eternal tinkering with developer options. Thank you from me Google.
2) GMS is a huge convenience for any app developer that needs tight control, including governments. They can secure their apps against users of any hat color. Add to that the possibility of hidden backdoors to support surveillance and Google's direct lobbying in EU. This makes it very difficult to go without it, even under the current anti-US EU direction and it will be the last that will be replaced in Europe.
3) There are various levels of "degoogling". From installing a totally open OS without or with microG, to just don't login to a Google account in stock Android. It's a spectrum but someone at the free edge will never have the same rights with one in the jailed edge.
4) Developer verif is NOT to prevent ad blocking. There is a simple and free method to block anything you like at DNS level: just select Private DNS and insert an appropriate URL for ads/trackers/porn etc, eg from controld.com. Find some other justification, like tight user control to continue sleeping with the governments or reach ultimate user surveillance with the upcoming children ident.
It's wild how far we've come, from IBM trying to lock down the PC to truly open hardware, to you now thanking Google for only mostly restricting what you can do with a device that you bought and own...
The rest of your content is just other forms of Google apologia.
This is honestly deeply disheartening... And on "hacker" news of all places...
I am not an advocate for the greedy tech companies but I am trying to give some rational perspective of the balance of power between them and us. If we want openness we cannot reach it with wishful saying.
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.
The irony of Chinese vendors providing a breath of fresh low-DRM air.
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.
Another example that microkernels actually do have market share.
- 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!)
Does this somehow also apply to developers in China? Are Chinese OSs (Vivo/Honor/Oppo/etc.) entirely forked off of Google's Android?
Is the solution to just a Chinese phone without the Play Store?
- https://news.ycombinator.com/item?id=47935853 (2 months ago, 889 comments)
- https://news.ycombinator.com/item?id=47139765 (4 months ago, 378 comments)
- https://news.ycombinator.com/item?id=47778274 (3 months ago, 68 comments)
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.
AI also says that it is possible to have push notifications without Google.
Yes. eg would have worked too. ie didn't seem like a good fit.
I really need to take the time and go with Graphene OS in this device. My bank N26 kind of still allows it, but they made it harder and harder to use with certain custom checks. Looks like in the future I need a separate banking phone and my daily driver.
The device works right now how I want it. I don't want anything to change.
Meanwhile the daily driver phones of my privacy-aware family members running up-to-date Lineage or Graphene OS with recent kernels and frequent updates constantly run into apps refusing to work for "security" reasons. It's a complete joke.
[1] https://news.ycombinator.com/item?id=48067119
[2] https://news.ycombinator.com/item?id=48555244
There are a lot of poor people, mostly brown people, who do not have the ability to get one of these licenses.
Some of them are feeding themselves with their ability to write, and Google is literally stealing that food from their mouths.
This is new to me, want to stay on top of it.
Just because someone is part of a particular demographic doesn’t mean they are suddenly incapable of harming them.
Separately, the process of installing apps that are outside a system app store and aren't verified has also changed, but this is not required by the developer verification feature, and the result seems like a wash to me. The first time you enable installing apps from other sources is harder, but this setting then persists across device upgrades, so the subsequent times go away completely. This now requires developer mode, but apps that check developer mode (I haven't found any in the US) can be mollified with a Tasker task to disable developer mode when launching those apps and enable it again after.
> Should a developer[...] elect to register themself with Google as a “verified” developer, they should expect to sign up for an account and pay a fee, surrender detailed personal information and upload government-issued identification, and then proceed to register the identifiers and signing keys for all the apps they intend to distribute (now or ever).
Those are big impediments to open development. The agreement developers sign states:
> 6.5 If You violate any of the Terms or if You distribute malware or other harmful applications, Google may terminate Your access to the ADC…
But they don't actually define "malware" anywhere in the document. Search HN if you want to hear horror stories about how google handles loose definitions and peoples' accounts.
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.
>The correct thing to complain about is requiring developer mode for unverified installs, which doesn't seem necessary
I had assumed the friction was to dissuade developers from not going through ADV. Isn't it partly for making malware distribution more traceable and campaigns easier to halt on GMS/certified Android systems?
https://news.ycombinator.com/item?id=48730729
More and more sites require you to use it be it github, or even fdroid (via gitlab).
Could one stop this by disabling OS updates?
They also have a bad reputation when it comes to updating their software. E.g. their initial Android 15 builds for FP4 had bad memory management issues, with a result that many people could only have one app in memory at the time, which made it impossible to switch between e.g. an app/browser and a password manager/payment app. Some of their updates would cause boot loops when there were fingerprint reader issues, etc. Currently a lot of users are dealing with an issue where apps hang when used over WiFi because IPv6 gets misconfigured when a router sends an IPv6 router advertisement with lifetime 0 (which e.g. Fritz!Boxes that are popular in Europe do). The issue has been there for over three months without any acknowledgement or fix from Fairphone.
Also, even though they do Android Security Bulletins and major releases (though very late), their phones often run ancient kernels and firmware with many known vulnerabilities. This is also the case if you run an alternative OS, because pretty much all of them use upstream trees. Also their firmware has Chinese TCL image processing blobs (might be a security/privacy issue for some people).
I think many of these issues stem from the fact that the development of both the hardware and the software is largely outsourced to a Chinese ODM (T2Mobile), who maintain everything, so there is a lot of delay in everything. My guess is that Fairphone as a company is mostly a PR/support/supply chain auditing (as in minerals/labor, not software supply chain) company, with all the development outsourced.
If you either buy a Fairphone from Murena (with /e/ OS) or from Iode (with Iode OS) or if you buy a standard one and install a version of Android without Google Play Services (like /e/ os or Iode), then you can still use FDroid.
IMHO F-Droid is just mad because their store model of "developer publishes source code, F-Droid builds and signs the APK" would put immense liability on F-Droid. After all with that model F-Droid owns the private signing keys and now has to register them with Google. If they let a single malware app slide through, Google might designate F-Droid as a malware provider and block everything ever published on F-Droid. (Sidenote: Last I checked F-Droid had nothing in their policies that forbids publishing malware, just that it has to be open source) If you ask me this store model was always stupid and completely missed the point of having signed APKs. I think they also have a newer model where they don't own the private keys anymore, but there's still tons of legacy apps.
Of course Google might have been open to talks about some kind of verified app store program allowing F-Droid to operate under different terms. But that's certainly out the window after all the fear mongering, hyperbole and straight up propaganda F-Droid has put out in recent months.
The whole point out of this outrage is alternative stores (like f-droid) can wholly and entirely be shut down on a whim without recourse.
Google is just trying how far they can push this.
And the setting is "optional", just do the 24h-waiting song and dance to change it, or use ADB. /s
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.
I still use the play store for some apps unfortunately. Also google maps, gmail, google messages (for rcs) and google fi. I'm not sure if theres anything close to the quality of traffic reporting as google maps, so it's hard to give up. The rest I will eventually move away from... Hopefully.
I have a home server with a reverse wireguard proxy for self hosting photos, calendars, etc.
I also have firefox with noscript blocking everything by default, but that's a big pain for an average person. Also it doesn't seem like firefox does a good job of anti-fingerprinting, but I haven't looked too deeply into that.
I even bought a tv that has adb access, and I removed a bunch of bloat, but it doesn't seem possible to remove the google launcher without causing huge system instability. I might just firewall it off.
There are a ton of open source alternatives to google products now, way more than the last time I tried moving away. It's time to leave.
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.
Apple was found not guilty.
Google was found anti-competitive.
In the appeal, Google asked the judge why Apple wasn't anti-comptitive and the judge told them that Apple wasn't anti-competitive because there were no competitors on their platform to compete with.
Google lost the appeal, an inflection point in tech was created, and Google wondered why the hell they tried being open when xbox, playstation, nintendo, apple, all get to do whatever they want on their closed platform.
It's incredible how little coverage that ruling gets despite how damning and detrimental to tech it's implications are.
Apple does not remotely allow that.
be sure that it's not, lots of people actually PREFER Android
I mean when people complained about Apple, the standard reply was "if you don't like Apple use Android,it's open! ".
Now when people complain about Android doing the same, the answer is how is it wrong if Google does it, when Apple has been doing this forever.
- https://en.wikipedia.org/wiki/Don%27t_be_evil
https://abc.xyz/investor/board-and-governance/google-code-of...
https://www.nytimes.com/2024/11/20/technology/google-antitru...
Do you have some examples? I have developer mode enabled and have never seen any apps complaining (and I have used a lot of different banking apps).
[1] https://droidify.app/
1. Ensure Droidify is not running. 2. Launch it. 3. Tell it to install or update to an app. 4. Receive an Android system prompt to approve the install/update. 5. Approve it. 6. Tell Droidify to install or update another app. 7. Reveive a system prompt to approve the action of step #3 again. 8. Approve it. 9. Receive system prompt to approve step #6. 10. Repeat #6 through #9 for more apps.
Workaround: Do steps #1 through #5.
Foxy Droid doesn't have this problem, but won't auto-download updates for you.
I agree. What do you suggest? How can we contribute to the resistance?
I've seen more outrage on HN posts about license changes than those related to this. I mean we are in the midst of one of the biggest rug pull of our lifetime and the response was not even remotely proportional. I wish it was a atleast a fraction of what it was during the SOPA act.
Not even businesses that could be hurt by entrenching Google more in the mobile space are acknowledging the issue.
That makes me think may be all the outrage at the SOPA time was probably "promoted" because it aligned with their commercial interests or may be Google is all too powerful and too deeply entrenched that nobody wants to upset them.
Install f-droid and all kinds of 3rd part apps now.
Install GrapheneOS. (I'm guilty of not having that done that,yet :( )
Sign the petition (https://keepandroidopen.org/).
An app becoming unavailable through remote attestation? New recaptcha? Document every case and send an e-mail to the DMA team.
Push back against these types of decisions internally. Rally your coworkers against them.
And if you're brave enough, talk to a journalist, or pull a mini-Snowden. Lord knows the company has secrets. I bet there's at least one email chain from some exec bragging about how this policy will squash Revanced, ad-blockers, etc.
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).
And perhaps because ten and twenty years ago, the sums stolen were small. Now they're in the billions.
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 didn't get scammed, I sometimes am curious on what the scam is so i lead them on a bit)
(They do something about other scams too. There was another thing they published recently, I didn't pay attention since no side effect of that concerned me, something to do with caller ID.)
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.
The scam apps are already in there. Please stop repeating google's propaganda.
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.
> That is because it is Google themselves who is propagating ADV. And once activated, this malevolent process has exactly one goal: to block you from running software by developers who haven’t been approved centrally by Google.
The rest of the article is a claim that Google's new terms of service amount to "malware is any software we [Google] don't like."
It seems like Google is aiming for its own walled garden.
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!
But even ignoring this - it is not for Alphabet/Google to decide whether, and how, I want protections. I want to be able to pick a sequence of bytes and install that as an application on my phone, without Alphabet having any say in whether that happens or not, and in fact without them knowing about it. It's my phone, not theirs, and the software should help me do what I need/want, not help them provide me their often-questionable services.
There won't be an open web, there won't be user installs, there won't be anonymity.
Everything will be identified, attested, and allowed only when Google permits it.
Nevermind them choking startups and small biz out of the oxygen they need to survive.
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.
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.
Is that right? Is that the future of Android as well?
If this is disseminated through Play Protect, does disabling Play Protect prevent triggering this?
PostmarketOS may not be perfect as of now, but it would advance and progress so much if people were hired to work on it and if people could buy a smartphone with it preinstalled. Bug reports and corrections would come much quicker as well as supported apps. Right now it is just a confidencial toy OS because of the lack of hardware support really, only a small number of smartphones are supported, only 2 of them are still sold and available as new (pinephone and pinephone pro), their specs are nowhere close to what you would expect for the price and they are only sold through a rather confidential online store.
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.
Like F-Droid, one of the most famous malware dens in the Android ecosystem.
And you’ll never reach a human to sort it out.
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.
Meanwhile, private Google services charge me the wrong prices, because I have a Payments profile in another country. It is associated with a Merchant account, which is linked to the Google Play Developer account.
The support concluded that this can also not be closed, and that I should close my Developer account first.
It's hell.
More importantly for Google though it's under extra scrutiny under the DSA at the EU wide level - so it doesn't have a clear right to not do business, it has to do terminations correctly with clear reasons set out in terms, there are mandatory notice periods etc.
that app is a done project and need only to be udpated when the target SDK becomes too old for the play store
My app has already been removed when they added the Privacy Policy requirement for the Advertising ID, where I did not update the app.
If you want to participate in the society, you will forever have to resort to shady tactics. Shady can be defined something as arbitrary as using GrapheneOS.
A temporary workaround like using alternatives like GrapheneOS for those affected will only delay the inevitable but it doesn't stop it at all.
This is real already. Recently saw a petition for EU to rein in big tech (there are several initiatives advocating this). Had this nagging voice at the back of my head ... what if signing that gets your Google Account terminated.
I'll leave it open to you whether I signed it.
For developers relying on any type of Google services, you'd be in for lots of pain.
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.
G+ was a failure; people refused to provide real names. Even Facebook's "real name policy" wasn't (and still isn't AFAIK) enforced at all. At one point, I had multiple phantom Google and Facebook accounts. Now I just self-host and eschew social media.
„Power tends to corrupt, and absolute power corrupts absolutely.“ - Lord Acton, 1887
Nowadays they are using the slogan “Crazy about chocolates, serious about people”
this is popping up a lot today for some reason. "don't be evil" is still in the code of conduct, as it always has been. it just isn't in the preface anymore after the restructuring under alphabet.
https://abc.xyz/investor/board-and-governance/google-code-of...
(its not like it stopped them, anyways)
More of us ask this question, the better we are heard. Except if this is exactly what they want, then we need to vote better.
To some degree, the closest we have to these situations besides getting flagged with TOS violations (whether real or false-flagged) in these companies are residents of countries that are either trade or economically sanctioned by the USA.
Thankfully we haven't seen something like an account ban and deletion incident for such cases, but the severe ones I can remember usually prohibit access entirely and that'd be scary if it extended to primary services that others rely on for auth.
You will be effectively locked out to services if it's all that's linked and that identity provider just decided you'd be persona non grata.
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.
There is a huge push towards cashless payments that has the same effect, especially as people increasingly use mobile payments.
BankID is used for login with every single Norwegian bank and government institution. There are alternatives, but they're invonvenient and sometimes bespoke per service.
I might be wrong but as far as I'm aware there's no legitimate APK downloads. And even if you get a hold of it, they use google services to attest the phone is secure, so there's no running it on a google-less OS.
The workaround used to be SMS codes, scratch off cards, and a physical 2FA codebrick. They cancelled SMS and the card, and currently you can't acquire a codebrick until they figure out some new bullshit about ID verification. Even the app is warning us it will quit functioning if we don't submit a passport and biometric face scan to some private company: https://bankid.no/en/help/confirm-identity
It's fucking dire.
I really hope we figure something out.
And a president could always just call up the CEOs and ask for their least favourite Norwegian to be cancelled without any paperwork.
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.
Have you tried updating your older iOS devices through a Mac?
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
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.
If you can't get the government to do this for you in Norway the US has very little hope currently.
We need some standard of minimal digital accessibility. Too much of our lives mediated by digital interactions with capricious systems.
Europeans are doing this to themselves.
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.
this is too funny coming from a continent constantly at war with itself
https://en.wikipedia.org/wiki/Democratic_backsliding_in_the_...
The new base agreement with the US, for instance, for practical purposes declares several areas in Norway to be US territory. It's rampantly against the Norwegian constitution of course, but that doesn't matter because the parliament seems to have agreed to just unanimously consent and not talk about it further.
Sea bed mining was a farce. Everyone said it was a terrible idea, including Equinor itself. Approved anyway. My assumption is that someone from US/NATO whispered "strategic minerals" into some party leader ears, and they suddenly decided to fast-track it without further discussion.
It would surprise me a lot if there weren't similar fast-tracked, no discussion, "it has been decided" deals about digital sovereignty. Norwegian politicians may not like the guy currently in charge over the Atlantic, but they view him as a temporary aberration and an occasion to prove their loyalty (to the crown, rather than the guy currently wearing it).
You are conflating default OS domains with google play services. Google play services is not bundled or installed by default, and is not given any kind of privileged access when it is installed. It does not handle OS domains or functionality, and GrapheneOS does not proxy its connections in any way.
As for the default domains of the OS, most are to GrapheneOS servers, not proxies. The only default OS connection that is proxied to google is remote key provisioning.
As for non-default connections, the only google proxies are widevine, for apps that use widevine, and SUPL, for location locking. SUPL can be disabled, and GOS is considering removing SUPL if network location is effective enough, or if they can host their own SUPL server viably.
https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#other-connections
These connections do NOT contain identifiable information. That is false.
Note RCS chats are also not proxied.
GrapheneOSs proxies do not collect and send any "unique keys" from apps. That is made up.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
They dont mention a proxy of RCS data because there isnt one. RCS messages do not require location data. None of the GrapheneOS proxies are related to RCS and the proxies do not know if an RCS message is received or sent.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
You did not read the FAQ at all.
> There is some vagueness regarding the RCS implementation message content. People claim Google can't read it, yet they specify they can read it in the client terms, and offer a managed RCS archiving service that works regardless of messaging client or supposed encryption. Is the RCS query proxied? Graphene does not mention it, but the simultaneous location data to use it is.
RCS is end to end encrypted on Google messages. The RCS spec also includes end to end encryption. There is no RCS proxy and RCS is handled by google messages. No other client for it exists at this time. The location data provided by SUPL is not given to apps, it is used for OS location that can be reported to apps. An app must have the location permission to have location data provided by the OS.
No such proxy exists in GrapheneOS. GrapheneOS does not intercept or proxy connections made by Google apps or other apps.
GrapheneOS doesn't include Google Mobile Services. Sandboxed Google Play is not part of GrapheneOS. Users can choose to install Google Play services, Google Play Store and other Google apps on GrapheneOS. Unlike a standard GMS Android device, those are installed as regular sandboxed apps with no special access. The feature provided by GrapheneOS is a compatibility layer coercing those to run as regular sandboxed apps if installed by users. It doesn't involve intercepting or proxying any connections.
> location data is proxied
Location request rerouting is an entirely local feature of the sandboxed Google Play compatibility layer. By default, it replaces the Google Play location library used by many apps with another implementation using the local OS location service instead of the local Google Play location service. This isn't intercepting or proxying connections.
Google Play has an optional network-based location service that's opt-out for a GMS Android OS although it's opt-in for sandboxed Google Play and people would also need to grant the required permissions to Play services which aren't normally needed.
GrapheneOS has an opt-in network-based location using Apple's service either directly or via a proxy. We'll also eventually have our own service with offline database download support as another option. We have to build our own database to use for this first.
You're misunderstand what location request rerouting means. It reroutes apps which normally request location from Play services to ask the regular Android location API for it instead. This doesn't involve servers other than optional network-based location for apps which support using the network or fused providers. Network-based location is opt-in for GrapheneOS.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
GrapheneOS doesn't proxy things in the way you claim in the first place. It doesn't proxy any connections involving carriers and doesn't proxy any connections made by Google apps. It doesn't come with Google apps and those would need to be installed by users.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
This is all completely untrue. GrapheneOS doesn't include with sandboxed Google Play. Sandboxed Google Play compatibility doesn't make any connections to GrapheneOS servers. It doesn't proxy anything through our servers. RCS via Google Messages doesn't involve our servers either.
You're misunderstanding our approach to all of these things. Location request rerouting means replacing the local Play services location API for apps using it with the OS location API. That means asking the OS for location rather than Play services. That isn't a connection to a server. It means that by default, apps using the Play services location SDK will work without Play services needing to be granted Location access based on the OS satellite-based location. If users enable network-based location for the OS location service then it will work for apps normally using the Google Play network or fused location providers. It's an entirely local compatibility layer as with the whole rest of it. Sandboxed Google Play compatibility layer has 0 connections to our servers and there's no reason it would need to connect to our servers.
GrapheneOS doesn't include Google Play services. Unlike LineageOS, GrapheneOS replaces all of the standard Android Open Source Project (AOSP) connections with our own servers. Also unlike LineageOS, GrapheneOS adds toggles for these connections providing a way to disable the ones which didn't already have a way to do it. See https://eylenburg.github.io/android_comparison.htm for a comparison across AOSP-based operating systems covering what's done with most of the standard AOSP connections. It doesn't cover everything such as the Certificate Transparency (CT) log list downloads added in Android 16 which are now used by default for enforcing CT for apps targeting Android 17.
> Graphene proxies what would go to Google on regular Android.
GrapheneOS doesn't include Google Play services. It has a compatibility layer enabling running Google Mobile Services apps including Google Play services and Google Play Store as regular sandboxed apps, but it doesn't come with those. Users can choose to install those in specific profiles.
> I am getting downvotes on this, but that is how their Google Play sandbox works. It is proxied on their server, not your phone. > > A non-Google copy of your Google pointed traffic is made. That is a fact. It is identifiable to you or they could not individually forward this or that. That is a fact.
GrapheneOS doesn't include sandboxed Google Play. It does not come with it. It's possible to install those apps on GrapheneOS and it provides a compatibility layer to make it work. The compatibility layer doesn't involve proxying anything to our servers.
> Extricating from Google is the answer. Not relating your RCS chats et al through a third party then to Google then to that third party and back to you.
No such thing exists in GrapheneOS. It doesn't include any Google apps and doesn't proxy any of the connections made by Google apps elsewhere if people install them.
GrapheneOS has low-level support for RCS but doesn't have an RCS app yet since the only one for Android which exists in practice anymore is Google Messages and Google apps aren't included in GrapheneOS. Google Messages can be installed by users on GrapheneOS and set as the SMS/MMS/RCS app instead of using our fork of AOSP Messaging but that's definitely not a default. We'll have our own RCS implementation in the future in our fork of AOSP MEssaging.
> They wrote an article on it a while back.
No, and it's definitely not how sandboxed Google Play works for people who choose to install it.
It sounds like you're misunderstanding what our sandboxed Google Play compatibility layer handles location requests made to Play services. For users who install sandboxed Google Play on GrapheneOS, our compatibility layer redirects apps requesting location from Play services to request it from the OS instead. This doesn't involve making any connections, it happens locally on the default. By default, only GNSS (satellite-based location) with A-GNSS (SUPL and PSDS) is used. GNSS is a receive-only system. We add toggles for configuring SUPL and PSDS with choices between GrapheneOS, Google or Off. PSDS are static database downloads covering the whole world so that's just another form of update download. We also add a toggle for opting into our network-based location implementation which uses Apple's service either directly or via a proxy. You seem to be confusing our location request redirection with intercepting connections and running those through our services which isn't what it involves at all. Our location request redirection avoids needing to grant Location access to Play services by making it use the standard Android OS location service instead as many apps already do. There's a toggle for this in case someone actually wants to use Google's location service with their network-based location instead of Apple such as if the Apple data for their area is awful.
> Graphene with Google Services is like calling up an Intel Agency and signing up to use them as your VPN.
GrapheneOS doesn't include Google Mobile Services, and our sandboxed Google Play compatibility layer doesn't work that way at all.
> Without Google Services, it is a way to degoogle a phone with an SD card slot and 3.5mm phone jack if Motorola continues on track, but I would prefer regular Lineage support than Graphene for that purpose in case the middle man aspect expands to non-Google Services apps later.
There's no such man-in-the-middle system in GrapheneOS as you claim. LineageOS does not replace the Google servers for all of the standard AOSP services as we do and doesn't provide similar settings to control all of those. GrapheneOS does not intercept/redirect Google services used by Google apps as you claim. It doesn't come with Google apps as you're describing either.
> I want straight no-google android with the chipset drivers so that calls and sms/mms messages work without Google getting a copy of every message sent and received, and I want it on phones with sd card slots and 3.5mm headphone ports.
GrapheneOS only includes support for using SMS/MMS via the carrier. There's no involvement from Google unless Google is your carrier or your carrier is using GCP to host their servers or something similar. Using Google's RCS services would require that you go out of the way to install Google Messages after first going out of the way to install sandboxed Google Play followed by setting Google Messages as your carrier-based messaging app and granting the required permissions to use RCS (Phone permission for Google Messages and Play services along with the ICC authentication toggle in the sandboxed Google Play settings).
You're talking about it as if us supporting installing these apps as regular sandboxed apps somehow makes that the default approach. That's not how any of this is supported at all. You have to go out of your way to install sandboxed Google Play or especially Google Messages. Those don't come with GrapheneOS.
GrapheneOS does not include Google Mobile Services or Google Messages. It does not intercept or proxy connections made by Google apps installed by users. None of that is part of how it works.
There are no such terms. In a comment further in this thread, you linked to inaccurate posts from an anonymous user on the Privacy Guides forum as your sources.
> They still run everything through Google services.
No, this is completely untrue. GrapheneOS doesn't have any mandatory connections in the first place.
> They are essentially a man in the middle to Google services.
No, GrapheneOS is a privacy and security hardened mobile OS. It isn't a proxy service and doesn't have any mandatory services. It does not come with Google Play services.
> I read their terms to mean that they could snarf everything that every graphene device would normally send to Google because they are "anonymizing it" before sending it to Google.
There are no such terms despite what's claimed in the incorrect anonymous posts you read.
> What we need is Android like Lineage that works on more devices than Pixels and simply have it without Google services at all.
GrapheneOS doesn't add a single Google service compared to the Android Open Source Project (AOSP). It replaces all of the standard AOSP default connections with our own servers by default. It also adds settings to control each of the connections. These settings mostly have a choice between GrapheneOS server, Standard (Google) server or Off.
LineageOS doesn't provide replacements for the Google services pr toggles for user control. This is covered in the third party comparison at https://eylenburg.github.io/android_comparison.htm which provides an overview of what's done with most of the default AOSP connections. The table doesn't cover all the standard connections, but GrapheneOS does deal with all of them by replacing the standard servers and provides settings to control the connections.
We add opt-in services for geocoding and network-based location as an alternative to the Google service. We host geocoding ourselves with Nominatim using the standard OpenStreetMap, Wikipedia and other supplementary data. Our network-based location service has a choice between Apple or our proxy to Apple but we plan to build our own database to host it directly.
SUPL which is a limited form of network-based location has a choice between our proxy to Google, Google or Off. SUPL can be fully replaced by enabling network-based location and leaving the default enabled static global PSDS database downloads enabled. We'll be hosting our own SUPL server using our network-based location database once the much easier to build subset of the database for cellular towers is ready for use.
Google certified devices use Google's hardware key attestation root and service so supporting that inherently has to use either a proxy (our default) or their server including for a non-Android-based OS running on the same hardware which wants hardware attestation support to be functional. That's tied to the hardware ecosystem based on certification, not software. Non-Google-certified devices will use a different service for attestation key provisioning, either hosted by GrapheneOS or a proxy to the service by the hardware provider or certification authority.
https://www.theguardian.com/law/2026/feb/18/international-cr...
The US made a Canadian judge a persona non grata for any firm domiciled in the US. All because she works for the ICC, and the ICC declared Netanyahu a war criminal (which is indisputible). Why is the US destroying worldwide trust in US businesses on behalf of a reviled nuclear armed hermit nation on the other side of the planet? Good question, but it is what it is.
This example that the US will spuriously use sanctions like this is why many nations are investigating ways to purge American financial systems and tech.
Governments need to wake up to this insane level of Evil. And other governments also need the US government responsible here, since they allow this to happen.
In objective terms this can be called a fascist system.
> A temporary workaround like using alternatives like GrapheneOS
The issue still is that so many services and functionalities are tied into private companies. States simply need to wake up now.
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.
The reason for this is really simple: every pirate wants to be an admiral, and every client state wants to be an empire. We as tech consumers hear "sovereign cloud" and think "cutting out undue influence that US tech companies have in the EU". The EC hears "building our own tech monopolies to lock in other countries into our stack". Using SKG as an example again, the whole reason why SKG started was because of a French company, Ubisoft, killing one of their games. Why would the EC ever overrule their own industrial interests?
The EC was specifically and expressly built to be an antidemocratic bulwark against popular sovereignty. The entire concept of dividing people up by nation-states is already an antidemocratic exercise - e.g. France has 69,000,000 residents and Malta has 520,000, but both get one seat at the EC. And because the EC is made up of nation-state appointees and not elected representatives, they have all the incentive in the world to stab their own people in the back. The EC is the designated villain that the """liberal""" side of Europe's government uses to shut down democratic control (and, sometimes, even liberalism itself).
Some have pointed out that this is deliberate (and, supposedly, therefore good): that Malta would never have joined the EU if they didn't have veto powers over whatever France wanted to do. My counterargument is that veto powers are the last resort of the rich and powerful. You can either have strong protections[0] on national identity, or you can have democracy, but not both.
[0] To be clear, the way we deal with democracy being a tyranny of the majority is with liberalism: we explicitly declare certain things to be "human rights" and thus more or less off limits to the democratic process. This list is generally fixed (or at least, difficult to change) and thus less ripe for abuse than, say, having an entire wing of the government dedicated solely to overruling the people that is active all the time.
He never had WhatsApp. He refuses to use google. Only till recently he started using signal. He has been using an old Nokia phone till he was forced to upgrade by his operator. He is European and here in Europe WhatsApp dominates. Despite all that and having a very social life, driven by work, he manages.
I recently ordered a Jolla phone. I don’t want to know about android. I might tolerate iOS. But shelling thousands of $ for a phone that is controlled by an external company…
I am looking out for messaging alternatives. I am at a point where I think linking your identity to a phone number is not right either.
Let’s say we should all wake the fuck up. This is not right. Having a phone with such spyware is a potential attack vector I don’t want to have on the most important device I own.
[1] https://forum.sailfishos.org/t/banking-apps-on-sailfish-os/1...
Why would you not trust Jolla? It was born from Nokia employees. GrapheneOS is a great alternative. Still Android though.
TFA is playing it up, but it is arguable that this is a real virus, except the shady hackers are Google.
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.
Unless you blog about it angrily enough that you somehow make it to the HN front page and some insider sees it and solves the problem for you.
Getting my own domain and setting up email on it is one of the best things I've ever done.
Even better: all providers of services with more than 100K users or 10% of country internet users should be forced to provide API to export / import data in open format.
It would be a lot harder to erect walled gardens if you're only serving a small subset of users - they would balk and leave at any attempt to prevent them from interacting with others outside of the ecosystem, and it would be a lot easier to do so.
Not yet found someone to do a SIM swap for me and get the 2FA code...
I had to submit my ID, my phone number, email.
Then to verify I had to give my address. They rejected my ID twice, so I had to submit driving licence.
I am several weeks in, and could not even produce a single app.
Their algorithm already rejected me, for no obvious reason.
I left behind Android and as many Google services as I could in 2020 and so far I've only been more vindicated with that decision over time.
I still use 2 Google services, of which neither would crumble me if lost (YouTube, and my old email which now acts as my spam inbox). I have lost accesses before, when I was still partially dependent, and had to give up my privacy to get access again, long enough to get off. It sucks but I do consider myself lucky that I was able to prevent the life crushing consequences that some people have had. Such a terrible company.
As a counterpoint to the right to the repair there should be a right to recover.
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).
Google has been dealing with accounts opened for fraud, spam and other evil bots since their inception. They should be nuking those. What's needed is some way of reverifying an account that was closed incorrectly, maybe some kind of independent ombudsman service or something to get the account back.
With the original story published by nytimes?
https://www.nytimes.com/2022/08/21/technology/google-surveil...
edit: ok, seems a different story, but better gets the point across
No, these services shouldn’t all be bundled under a single account…
I am not a US citizen, but a EU one (well, since we have seriously rogue and toxic EU states, I dunno how long it will last).
And guess what, the handling of the issue of technical interop for administration online services is done... at the top of the top of the political power: in my EU country, only the president and prime minister do define it. Yep, you read well, it is THAT MUCH important: parliament, no power over it, 'technical authorities' have actually no real power over anything, etc. It requires the same level of power than deciding to make more nukes.
Basically, in 2015/2016 our president/prime minister at that time literaly gave all the administration (and dependencies) online services to big tech (a technical document which is basically 'law' with a content 'opening the gate' for big tech). Well, I say 'they gave it', but they could have 'sold it'... we have a department in our DOJ to monitor past politicians who could have set up some public money channels in order to benefit from it, often indirectly, afterwards. The following president and prime ministers did change nothing... how deep the rabbit hole goes? Brain washing via hardcore lobbying? Corruption?
IRL, you had country administration related web sites, working more that fine with "any browsers", small and big, citizen made, small company made, now it is over, they were all broken for web apps which do work only with whatwg cartel web engines with their abomination of "computer language" requiring an even worse SDK. Same with file formats.
There is light though, if this document of technical 'law' is properly modified, the whole administration and dependencies have 3 years to restore simple web sites and support minimal and subset of file formats.
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.
The Play Store still has a problem with shady apps years later. If Google wants to be more like Apple, they should start with better curation in their own store.
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.
Perhaps it happens because the slope is called out...
Regulation may try to stop it but history has shown some have slid to the point of no return or past a point where people can care enough to build out of.
Prevention is better than retroactively fixing stuff.
But I've come to realize there are serious downsides to letting things run their course too. Some changes are very hard to roll back (famous 'cat's out of the bag') just taking a lot of time to reverse if ever. For example, once there is a long term contractual agreement, if one parties decides to roll back they may just not be able to until the contract expires (like renting land; or worse, selling). A change in software systems for example that need backward compatibility can be quite difficult in technical and nontechnical ways.
I think people need to also keep some sympathy for the protests and let people protest more. I'm leaning more toward: if in doubt, provide visibility to a cause (even if not full support). It's okay to save yourself some energy (in particular for the most important causes). Some things might have to run their course for people to understand they were valuable, and we will probably have to eat some frogs as a consequence. Don't lose you sanity ;) (As the saying goes, "Don't you dare go hollow.")
Yes. You see it already.
"Actually it is good that I can't run programs that haven't been approved by Google on my own device."
So this concern cannot be dismissed with just "slippery slope falacy", it's a new vector of the same power grab strategy.
You can say "Classic slippery slope fallacy." to whatever seems like that to you.
This is an antipattern to scientific thinking as you can frame something x and then say all x are like this, look I created this framework to think about x. But in reality there is no empirical basis for this thought. And it serves no purpose other than doing more argument or winning arguments.
In the end what you wrote equates to "I don't think all of this will happen".
Chaning many possibilities makes the outcome less and less likely obviously.
Also the same principle applies to most religions I know of, for example:
- Assume there is God
- Assume it did create universe.
- Assume x
...
Then this also fits the same pattern and be called the "x fallacy" but it is useless to create an argument like this. This is useless mainly because this thinking pattern is ubiquitous in any world view.
More productive discussion might be to pick some steps in the theory they chained together and argue on that imo.
Malware is something that maliciously breaks your computer.
This maliciously breaks my computer so it's malware. There's no difference between this and the ILOVEYOU virus, except the delivery mechanism.
This claim is made by FDroid with no evidence. They make this scary claim which goes against everything Google has claimed so far. They are a biased party, and I can't trust their opinion. I would appreciate if they shared a more in depth investigation or a way to verify there big claim.
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.
I have such a phone and the "virus" has not been installed to it. There is no evidence behind this claim.
>with as many as 4 billion Android handsets and tablets estimated to have already been contaminated
This is misleading wording. It's just as true to say that as many as 1 trillion devices have been contaminated. It is state an impossible upper bound to drum up fear.
>this trojan horse runs surreptitiously in the background as a system service with full root privileges
Services in Android do not run with root privileges. Android practices the principal of least privilege where individual permissions are granted instead of giving it blanket access to everything.
>The service cannot be blocked, disabled, or removed.
This is unlikely to be true. You can most likely use "am" to disable it.
>In fact, Play Protect is itself the vector through which this virus is transmitted and installed.
This is probably false. Realistically it's going to be transmitted via the google play store like all other play service components.
>There are many things we don’t know about what to expect on September 30
>What will happen if I try to install or launch the F-Droid app?
Once active if FDroid not verified the user has to use adb or have enabled sideloading by unverified developers. If it's already installed the user can launch it.
>What will happen to all the apps I’ve installed through F-Droid? Will they be disabled? Deleted?
Nothing will happen to them.
>If apps that I rely on are suddenly disappeared, what happens to the data they contain? Can I still retrieve it?
Nothing will happen. But if Play Protect were to flag malware it manually asks you if you want to delete the app. If you delete the app the data will be lost.
If you can just disable it with the activity manager or similar, I don't think Google would provide another workaround with a wait time and everything - and that only after a lot of public pressure. It's claimed to be a security feature against scams, and scammers can theoretically let you open up an adb shell and run an am command, so that would negate the safety. (That this never happens in practice imo demonstrates that it's just about ecosystem control and not actually for user safety.)
I agree on the root thing though. I don't have a device here that has this service running so I can't check the process permissions for myself, but it seems extremely doubtful that it runs as uid 0. Fdroid could have dumbed the technical permission level down in more accurate way
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?
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.