This is real already. Recently saw a petition for EU to rein in big tech (there are several initiatives advocating this). Had this nagging voice at the back of my head ... what if signing that gets your Google Account terminated.
I'll leave it open to you whether I signed it.
For developers relying on any type of Google services, you'd be in for lots of pain.
If you are wrongly charged a significant amount by either Google or Apple and their service is of no help, what would you do?
Most people would weigh the options, then just eat the cost than anger them with a chargeback and lose their email/phone access. That's self-censorship financially too.
What if Google reinstates their old G+ and YouTube real name policy for its accounts. We would protest but give them the proof grudgingly and it can position itself as one of the core part of online ID verification push currently going on.
G+ was a failure; people refused to provide real names. Even Facebook's "real name policy" wasn't (and still isn't AFAIK) enforced at all. At one point, I had multiple phantom Google and Facebook accounts. Now I just self-host and eschew social media.
„Power tends to corrupt, and absolute power corrupts absolutely.“ - Lord Acton, 1887
Nowadays they are using the slogan “Crazy about chocolates, serious about people”
this is popping up a lot today for some reason. "don't be evil" is still in the code of conduct, as it always has been. it just isn't in the preface anymore after the restructuring under alphabet.
https://abc.xyz/investor/board-and-governance/google-code-of...
(its not like it stopped them, anyways)
More of us ask this question, the better we are heard. Except if this is exactly what they want, then we need to vote better.
To some degree, the closest we have to these situations besides getting flagged with TOS violations (whether real or false-flagged) in these companies are residents of countries that are either trade or economically sanctioned by the USA.
Thankfully we haven't seen something like an account ban and deletion incident for such cases, but the severe ones I can remember usually prohibit access entirely and that'd be scary if it extended to primary services that others rely on for auth.
You will be effectively locked out to services if it's all that's linked and that identity provider just decided you'd be persona non grata.
They removed SMS 2FA options recently, the only non-tech monopoly method is a 2fa codebrick that's getting harder and harder to acquire (there are new ridiculous facial ID and passport scanning requirements, run by a private corporation, in order to get one).
It's garbage and getting worse. And it seems no one cares our entire lives exist at the whim of two US tech monoliths.
There is a huge push towards cashless payments that has the same effect, especially as people increasingly use mobile payments.
BankID is used for login with every single Norwegian bank and government institution. There are alternatives, but they're invonvenient and sometimes bespoke per service.
I might be wrong but as far as I'm aware there's no legitimate APK downloads. And even if you get a hold of it, they use google services to attest the phone is secure, so there's no running it on a google-less OS.
The workaround used to be SMS codes, scratch off cards, and a physical 2FA codebrick. They cancelled SMS and the card, and currently you can't acquire a codebrick until they figure out some new bullshit about ID verification. Even the app is warning us it will quit functioning if we don't submit a passport and biometric face scan to some private company: https://bankid.no/en/help/confirm-identity
It's fucking dire.
I really hope we figure something out.
And a president could always just call up the CEOs and ask for their least favourite Norwegian to be cancelled without any paperwork.
I cannot install any iOS software without being logged into my Apple account, not even an alternative app store.
It would be perfect on my older iDevices, but they don't let me log in anymore “because the OS is too old”. And guess what: I cannot update the OS without being logged in. I never logged out of those iDevices, Apple did that from their end.
Have you tried updating your older iOS devices through a Mac?
Only users based in Brazil, Japan, or the European Union are able to install apps through alternative app distribution. The country or region of your *Apple Account* must be set to one of those countries or regions, and you must physically be located there. [0]
UPDATE: Also tried to install onside.io. No luck. The same popup:
Cannot Install App: You are not eligible to install apps from "onside.io".
[0] https://support.apple.com/en-us/117767 https://support.apple.com/en-us/118110
We need corporations and governments to stop locking down and gatekeeping vital software to closed ecosystems.
A Linux phone doesn't help me when my government's 2FA system (BankID) only runs on Android and IOS phones and can only be acquired with an app store account.
If you can't get the government to do this for you in Norway the US has very little hope currently.
We need some standard of minimal digital accessibility. Too much of our lives mediated by digital interactions with capricious systems.
Europeans are doing this to themselves.
Now, my card info did in fact get compromised recently, and that's probably why I ended up needing that stronger auth flow. But the fact that I literally can't complete that stronger bank authentication without Google or Apple is... yeah. No.
I have since signed up for a different credit card that I plan to use from here on out.
I mean, tbf the situation was fine until the US transitioned to an autocracy, and the companies went full surveillance state evil, completely supporting the autocracy. Which is a relatively recent development.
But sure.
Most places here are working as fast as possible to decouple from any reliance on the US, and I would expect Norway to switch to the new EU digital ID system currently in development.
this is too funny coming from a continent constantly at war with itself
https://en.wikipedia.org/wiki/Democratic_backsliding_in_the_...
The new base agreement with the US, for instance, for practical purposes declares several areas in Norway to be US territory. It's rampantly against the Norwegian constitution of course, but that doesn't matter because the parliament seems to have agreed to just unanimously consent and not talk about it further.
Sea bed mining was a farce. Everyone said it was a terrible idea, including Equinor itself. Approved anyway. My assumption is that someone from US/NATO whispered "strategic minerals" into some party leader ears, and they suddenly decided to fast-track it without further discussion.
It would surprise me a lot if there weren't similar fast-tracked, no discussion, "it has been decided" deals about digital sovereignty. Norwegian politicians may not like the guy currently in charge over the Atlantic, but they view him as a temporary aberration and an occasion to prove their loyalty (to the crown, rather than the guy currently wearing it).
You are conflating default OS domains with google play services. Google play services is not bundled or installed by default, and is not given any kind of privileged access when it is installed. It does not handle OS domains or functionality, and GrapheneOS does not proxy its connections in any way.
As for the default domains of the OS, most are to GrapheneOS servers, not proxies. The only default OS connection that is proxied to google is remote key provisioning.
As for non-default connections, the only google proxies are widevine, for apps that use widevine, and SUPL, for location locking. SUPL can be disabled, and GOS is considering removing SUPL if network location is effective enough, or if they can host their own SUPL server viably.
https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#other-connections
These connections do NOT contain identifiable information. That is false.
Note RCS chats are also not proxied.
GrapheneOSs proxies do not collect and send any "unique keys" from apps. That is made up.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
They dont mention a proxy of RCS data because there isnt one. RCS messages do not require location data. None of the GrapheneOS proxies are related to RCS and the proxies do not know if an RCS message is received or sent.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
You did not read the FAQ at all.
> There is some vagueness regarding the RCS implementation message content. People claim Google can't read it, yet they specify they can read it in the client terms, and offer a managed RCS archiving service that works regardless of messaging client or supposed encryption. Is the RCS query proxied? Graphene does not mention it, but the simultaneous location data to use it is.
RCS is end to end encrypted on Google messages. The RCS spec also includes end to end encryption. There is no RCS proxy and RCS is handled by google messages. No other client for it exists at this time. The location data provided by SUPL is not given to apps, it is used for OS location that can be reported to apps. An app must have the location permission to have location data provided by the OS.
No such proxy exists in GrapheneOS. GrapheneOS does not intercept or proxy connections made by Google apps or other apps.
GrapheneOS doesn't include Google Mobile Services. Sandboxed Google Play is not part of GrapheneOS. Users can choose to install Google Play services, Google Play Store and other Google apps on GrapheneOS. Unlike a standard GMS Android device, those are installed as regular sandboxed apps with no special access. The feature provided by GrapheneOS is a compatibility layer coercing those to run as regular sandboxed apps if installed by users. It doesn't involve intercepting or proxying any connections.
> location data is proxied
Location request rerouting is an entirely local feature of the sandboxed Google Play compatibility layer. By default, it replaces the Google Play location library used by many apps with another implementation using the local OS location service instead of the local Google Play location service. This isn't intercepting or proxying connections.
Google Play has an optional network-based location service that's opt-out for a GMS Android OS although it's opt-in for sandboxed Google Play and people would also need to grant the required permissions to Play services which aren't normally needed.
GrapheneOS has an opt-in network-based location using Apple's service either directly or via a proxy. We'll also eventually have our own service with offline database download support as another option. We have to build our own database to use for this first.
You're misunderstand what location request rerouting means. It reroutes apps which normally request location from Play services to ask the regular Android location API for it instead. This doesn't involve servers other than optional network-based location for apps which support using the network or fused providers. Network-based location is opt-in for GrapheneOS.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
GrapheneOS doesn't proxy things in the way you claim in the first place. It doesn't proxy any connections involving carriers and doesn't proxy any connections made by Google apps. It doesn't come with Google apps and those would need to be installed by users.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
This is all completely untrue. GrapheneOS doesn't include with sandboxed Google Play. Sandboxed Google Play compatibility doesn't make any connections to GrapheneOS servers. It doesn't proxy anything through our servers. RCS via Google Messages doesn't involve our servers either.
You're misunderstanding our approach to all of these things. Location request rerouting means replacing the local Play services location API for apps using it with the OS location API. That means asking the OS for location rather than Play services. That isn't a connection to a server. It means that by default, apps using the Play services location SDK will work without Play services needing to be granted Location access based on the OS satellite-based location. If users enable network-based location for the OS location service then it will work for apps normally using the Google Play network or fused location providers. It's an entirely local compatibility layer as with the whole rest of it. Sandboxed Google Play compatibility layer has 0 connections to our servers and there's no reason it would need to connect to our servers.
GrapheneOS doesn't include Google Play services. Unlike LineageOS, GrapheneOS replaces all of the standard Android Open Source Project (AOSP) connections with our own servers. Also unlike LineageOS, GrapheneOS adds toggles for these connections providing a way to disable the ones which didn't already have a way to do it. See https://eylenburg.github.io/android_comparison.htm for a comparison across AOSP-based operating systems covering what's done with most of the standard AOSP connections. It doesn't cover everything such as the Certificate Transparency (CT) log list downloads added in Android 16 which are now used by default for enforcing CT for apps targeting Android 17.
> Graphene proxies what would go to Google on regular Android.
GrapheneOS doesn't include Google Play services. It has a compatibility layer enabling running Google Mobile Services apps including Google Play services and Google Play Store as regular sandboxed apps, but it doesn't come with those. Users can choose to install those in specific profiles.
> I am getting downvotes on this, but that is how their Google Play sandbox works. It is proxied on their server, not your phone. > > A non-Google copy of your Google pointed traffic is made. That is a fact. It is identifiable to you or they could not individually forward this or that. That is a fact.
GrapheneOS doesn't include sandboxed Google Play. It does not come with it. It's possible to install those apps on GrapheneOS and it provides a compatibility layer to make it work. The compatibility layer doesn't involve proxying anything to our servers.
> Extricating from Google is the answer. Not relating your RCS chats et al through a third party then to Google then to that third party and back to you.
No such thing exists in GrapheneOS. It doesn't include any Google apps and doesn't proxy any of the connections made by Google apps elsewhere if people install them.
GrapheneOS has low-level support for RCS but doesn't have an RCS app yet since the only one for Android which exists in practice anymore is Google Messages and Google apps aren't included in GrapheneOS. Google Messages can be installed by users on GrapheneOS and set as the SMS/MMS/RCS app instead of using our fork of AOSP Messaging but that's definitely not a default. We'll have our own RCS implementation in the future in our fork of AOSP MEssaging.
> They wrote an article on it a while back.
No, and it's definitely not how sandboxed Google Play works for people who choose to install it.
It sounds like you're misunderstanding what our sandboxed Google Play compatibility layer handles location requests made to Play services. For users who install sandboxed Google Play on GrapheneOS, our compatibility layer redirects apps requesting location from Play services to request it from the OS instead. This doesn't involve making any connections, it happens locally on the default. By default, only GNSS (satellite-based location) with A-GNSS (SUPL and PSDS) is used. GNSS is a receive-only system. We add toggles for configuring SUPL and PSDS with choices between GrapheneOS, Google or Off. PSDS are static database downloads covering the whole world so that's just another form of update download. We also add a toggle for opting into our network-based location implementation which uses Apple's service either directly or via a proxy. You seem to be confusing our location request redirection with intercepting connections and running those through our services which isn't what it involves at all. Our location request redirection avoids needing to grant Location access to Play services by making it use the standard Android OS location service instead as many apps already do. There's a toggle for this in case someone actually wants to use Google's location service with their network-based location instead of Apple such as if the Apple data for their area is awful.
> Graphene with Google Services is like calling up an Intel Agency and signing up to use them as your VPN.
GrapheneOS doesn't include Google Mobile Services, and our sandboxed Google Play compatibility layer doesn't work that way at all.
> Without Google Services, it is a way to degoogle a phone with an SD card slot and 3.5mm phone jack if Motorola continues on track, but I would prefer regular Lineage support than Graphene for that purpose in case the middle man aspect expands to non-Google Services apps later.
There's no such man-in-the-middle system in GrapheneOS as you claim. LineageOS does not replace the Google servers for all of the standard AOSP services as we do and doesn't provide similar settings to control all of those. GrapheneOS does not intercept/redirect Google services used by Google apps as you claim. It doesn't come with Google apps as you're describing either.
> I want straight no-google android with the chipset drivers so that calls and sms/mms messages work without Google getting a copy of every message sent and received, and I want it on phones with sd card slots and 3.5mm headphone ports.
GrapheneOS only includes support for using SMS/MMS via the carrier. There's no involvement from Google unless Google is your carrier or your carrier is using GCP to host their servers or something similar. Using Google's RCS services would require that you go out of the way to install Google Messages after first going out of the way to install sandboxed Google Play followed by setting Google Messages as your carrier-based messaging app and granting the required permissions to use RCS (Phone permission for Google Messages and Play services along with the ICC authentication toggle in the sandboxed Google Play settings).
You're talking about it as if us supporting installing these apps as regular sandboxed apps somehow makes that the default approach. That's not how any of this is supported at all. You have to go out of your way to install sandboxed Google Play or especially Google Messages. Those don't come with GrapheneOS.
GrapheneOS does not include Google Mobile Services or Google Messages. It does not intercept or proxy connections made by Google apps installed by users. None of that is part of how it works.
There are no such terms. In a comment further in this thread, you linked to inaccurate posts from an anonymous user on the Privacy Guides forum as your sources.
> They still run everything through Google services.
No, this is completely untrue. GrapheneOS doesn't have any mandatory connections in the first place.
> They are essentially a man in the middle to Google services.
No, GrapheneOS is a privacy and security hardened mobile OS. It isn't a proxy service and doesn't have any mandatory services. It does not come with Google Play services.
> I read their terms to mean that they could snarf everything that every graphene device would normally send to Google because they are "anonymizing it" before sending it to Google.
There are no such terms despite what's claimed in the incorrect anonymous posts you read.
> What we need is Android like Lineage that works on more devices than Pixels and simply have it without Google services at all.
GrapheneOS doesn't add a single Google service compared to the Android Open Source Project (AOSP). It replaces all of the standard AOSP default connections with our own servers by default. It also adds settings to control each of the connections. These settings mostly have a choice between GrapheneOS server, Standard (Google) server or Off.
LineageOS doesn't provide replacements for the Google services pr toggles for user control. This is covered in the third party comparison at https://eylenburg.github.io/android_comparison.htm which provides an overview of what's done with most of the default AOSP connections. The table doesn't cover all the standard connections, but GrapheneOS does deal with all of them by replacing the standard servers and provides settings to control the connections.
We add opt-in services for geocoding and network-based location as an alternative to the Google service. We host geocoding ourselves with Nominatim using the standard OpenStreetMap, Wikipedia and other supplementary data. Our network-based location service has a choice between Apple or our proxy to Apple but we plan to build our own database to host it directly.
SUPL which is a limited form of network-based location has a choice between our proxy to Google, Google or Off. SUPL can be fully replaced by enabling network-based location and leaving the default enabled static global PSDS database downloads enabled. We'll be hosting our own SUPL server using our network-based location database once the much easier to build subset of the database for cellular towers is ready for use.
Google certified devices use Google's hardware key attestation root and service so supporting that inherently has to use either a proxy (our default) or their server including for a non-Android-based OS running on the same hardware which wants hardware attestation support to be functional. That's tied to the hardware ecosystem based on certification, not software. Non-Google-certified devices will use a different service for attestation key provisioning, either hosted by GrapheneOS or a proxy to the service by the hardware provider or certification authority.
https://www.theguardian.com/law/2026/feb/18/international-cr...
The US made a Canadian judge a persona non grata for any firm domiciled in the US. All because she works for the ICC, and the ICC declared Netanyahu a war criminal (which is indisputible). Why is the US destroying worldwide trust in US businesses on behalf of a reviled nuclear armed hermit nation on the other side of the planet? Good question, but it is what it is.
This example that the US will spuriously use sanctions like this is why many nations are investigating ways to purge American financial systems and tech.
Governments need to wake up to this insane level of Evil. And other governments also need the US government responsible here, since they allow this to happen.
In objective terms this can be called a fascist system.
> A temporary workaround like using alternatives like GrapheneOS
The issue still is that so many services and functionalities are tied into private companies. States simply need to wake up now.
I’m not even being cynical — it would probably just increase the amount of government contract cash awarded to them. Control makes governing a lot easier, control is what tech companies have, and to varying degrees, it’s for sale.
Governments are made up of people. People who have at best median level understanding of the things they are ruling about but great self-interest in following the biggest purse to which they can attach themselves.
The reason for this is really simple: every pirate wants to be an admiral, and every client state wants to be an empire. We as tech consumers hear "sovereign cloud" and think "cutting out undue influence that US tech companies have in the EU". The EC hears "building our own tech monopolies to lock in other countries into our stack". Using SKG as an example again, the whole reason why SKG started was because of a French company, Ubisoft, killing one of their games. Why would the EC ever overrule their own industrial interests?
The EC was specifically and expressly built to be an antidemocratic bulwark against popular sovereignty. The entire concept of dividing people up by nation-states is already an antidemocratic exercise - e.g. France has 69,000,000 residents and Malta has 520,000, but both get one seat at the EC. And because the EC is made up of nation-state appointees and not elected representatives, they have all the incentive in the world to stab their own people in the back. The EC is the designated villain that the """liberal""" side of Europe's government uses to shut down democratic control (and, sometimes, even liberalism itself).
Some have pointed out that this is deliberate (and, supposedly, therefore good): that Malta would never have joined the EU if they didn't have veto powers over whatever France wanted to do. My counterargument is that veto powers are the last resort of the rich and powerful. You can either have strong protections[0] on national identity, or you can have democracy, but not both.
[0] To be clear, the way we deal with democracy being a tyranny of the majority is with liberalism: we explicitly declare certain things to be "human rights" and thus more or less off limits to the democratic process. This list is generally fixed (or at least, difficult to change) and thus less ripe for abuse than, say, having an entire wing of the government dedicated solely to overruling the people that is active all the time.