- 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.
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.
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.
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.
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.
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.
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.
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
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
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.
That's debian based with gnome and seems to be built by capable people. Also, it can run android apps.
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.
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.
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.
>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.
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.
https://www.androidauthority.com/grapheneos-motorola-partner...
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.
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.
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.
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
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.
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.
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...
Why do you choose to die on that hill? It's ridiculous!
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.
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).
So, Android?
Which supports only Pixel devices.
I never treat my (Android) phone as secure anyway.
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
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...)
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
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.
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.
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?
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.
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)
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
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.
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.
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.
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.
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"?
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.
Could one stop this by disabling OS updates?
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
Using Android fork has been a transition step.
- they're among the most expensive (I could afford that if needed though)
- they don't allow hardware unlock (ehh.. what's the point, then, if I get a locked-down device with Chinese surprises!)
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?
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.
- 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)
https://news.ycombinator.com/item?id=48730729
More and more sites require you to use it be it github, or even fdroid (via gitlab).
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.
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.
Yes. eg would have worked too. ie didn't seem like a good fit.
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.
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.
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
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.
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.
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://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. 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.
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!
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.
> 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.
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.
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.
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.
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).
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.
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.
..."The new system improves privacy and security by using separate attestation signing keys for each app ..."
RCS requires location data for many carriers. When sending an RCS message or receiving one that data is shared with Google via the supl... Server. That is fundamental to how RCS works on numerous carriers. It may be possible to work without it, but some carriers require it . Graphene explicitly states that they proxy that. You disable that and send it straight to Google if you wish, but GNSS location data is technologically required for RCS to work on many carriers. When RCS works without it, it because the location is known via another method.
<grapheneos.org/faq#other-connections>
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.
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.
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.