I don't care about any of these, I just want to be able to have whatever Google pay does without Google.
You could claim that's not an android problem but if you do I don't think you've ever had to explain to people your phone doesn't have a Google Play store.
It is? I haven’t carried my wallet around in years, because Apple Wallet does everything I need. Concert tickets, boarding passes, bank cards, public transport cards, etc. A physical wallet and cards in comparison feels like stone age technology.
Banks and card networks will only accept proprietary shitware as payment. Would you rather keep the malware confined to a separate processor chip or would you let it run on your phone?
In other words, would you like to have your physical card to be lost or stolen and someone paying with it? As small amounts don’t ask for a pin confirmation. Having my phone stolen is pretty much another level of attack.
Yes... that $25 if they manage to get even that before it is blocked I can live with. Loosing my phone, even if they can't do anything with it is a whole other scenario. Now I can't even get home.
> would you like to have your physical card to be lost or stolen and someone paying with it?
I don't really care, as I'm protected from fraud by the card issuer and regulations in my country.
> Having my phone stolen is pretty much another level of attack.
Stealing a wallet or a phone seems just about the same level of difficulty.
And you can trick an iPhone into believing you're a transit terminal and charge arbitrary amounts to real credit cards, without unlocking the phone. (And Apple thinks this is a feature.) The attack requires specialized hardware and physical access, but if you've stolen the phone, that's fine.
(Yes, I know, this article is about Android. But most people where I live have iPhones, even if I don't.)
And your battery goes empty, and you just lost everything. Or your phone falls to the ground and breaks.
And to add to payments, the store loyalty apps are the worst... Lidl over here has an app only (no physical loyalty card), and they should be hanged for developing that... first of all, you're waiting in line while a grandma takes her phone out of her purse, then unlock it, and of course android is not satisfied with her fingerprint right then but also wants a pin... then all apps, then scroll down to L, find LidlPlus app, tap on it... QR code? Nope, not yet! First you get a daily coupon wheel of fortune, tap, wait for it to spin, see what your award is... and if it's something that she just bought, she has to manually activate that coupon in the menu (again, tap, find, tap, tap back), and then click the card button to get the qr code to scan... it's literally minutes sometimes of just waiting, instead of scanning a simple qr code on a plastic card pulled from the wallet.
We even had one of our telcos break down (full internet loss, country wide), POS terminals not working at all, and there are actually people with zero cash with them, not even like 50 euros (for just-in-case (like this))... and then you have to wait for them to turn around, take their stuff back and go home hungry.
No it’s not, all of my and my extended family cards (for… like a decade!) are never even leave the envelope they come in. I’m not sure I personally know people who use physical cards over Google or Apple Pay. I have seen the cards being used in the wild, of course. But I’m having hard time remembering anyone I personally know who does that.
How strange that culture is so different in different places. You can just start using them, though. Literally just swipe your card whenever you would swipe your phone.
So, the argument is that it is popular? I'm not arguing against that...
That people trade anything for even just perceived convenience? That isn't news either, but it does explain a lot of the sad state of affairs we are struggling with today.
I'm starting to come the the same conclusion, but not for practical reasons. My thinking is about privacy. If I buy some chocolates from retailer X (with or without their loyalty system), these parties will know what I purchased and where: The retailer, the bank, the merchant (visa/mc), wallet provider (Google/Apple/Samsung). Any upstream 3rd parties for analytics, big data warehouses, ai companies (fraud detection, spending predictions), marketing companies, research companies, manufacturers. Then there are bluetooth beacons, microphones, cameras, facial recognition, keyboard/screen capture (Gboard, Samsung Keyboard, Whatsapp texts). Then there is sms and popup notification on device that gets ingested by x amount of systems too. So the whole pipe just exists to gather as much as possible data to sell me more stuff. Having a card will take some of them out of the loop or less rich metadata than using a digital wallet.
A card is a good step to reduce that. I want to go farther and pay cash as much as possible, but it's not trivial to manage when all I have is a pocket full of coins. Is there a 3D printed wallet with slots sized for European coins so you can quickly identify and extract the coins you need instead of rummaging through a mixed pocket?
We desperately need to break Visa's stranglehold on access to the consumer side of commerce. As long as everyone's only innovating and competing on the merchant side of things, we're not really going to get anywhere.
Many EU online shops accept SEPA payment. It isn't convenient, because it's a push payment (giro) which means the site can't stick it in the middle of the order flow and expect it to take a few seconds. Some users might have to visit a bank branch to send payment.
Not all banks do SEPA Instant, yeah. I suppose the answer to that is connecting using PSD2 and sending the payment request then checking payment actually went out (using something like https://gocardless.com/). Many countries also have local bank link systems (e.g. in the Baltics it’s common to have dedicated buttons in the payment form for the big 3 or 4 banks everyone uses).
I’m talking about in-person payments though. It would be so easy to implement QR payments backed by the existing SEPA Instant rails. Many bank apps already understand EPC QR codes (usually found on invoices), so shops could just show these to accept payment. In case your bank doesn’t support SEPA Instant, you could show the cashier the receipt in your bank app, which, well, horribly insecure, but probably fine for low-stakes cases like grocery shopping (you don’t want to be banned from your grocery store chain for forging a 35 € payment).
Are you prepared to protect customers by refunding them if they are victims of fraud when using your payment system? Visa and MasterCard are prepared to do that. That's how they could convince consumers to use their cards without worrying.
Millions of card transactions are made every day. If consumers worried, they wouldn't have credit or debit cards and they wouldn't use credit or debit cards.
What a single hacker writes is on the other hand just what he wrote.
Yep, the duopoly is pretty strong. There are national card networks (which sometimes make their own tap-to-pay apps!), but if you want universal acceptance you’ve got to deal with the big two.
You can sidestep this however by not dealing with cards. I’d look into various QR payment schemes.
The whole GrapheneOS thing is a bit of a joke. So you either have to buy google hardware or you run google software.
Anyway, looking forward to the widespread introduction of Wero. Maybe there will be some options for third party roms in the name of digital soveranity. Seems like they want to make the EUDI wallet for digital documents no-google capable for that reason at least.
You think Google puts backdoors in their hardware? They've consistently been one of the most open hardware brands since the start, always allowing bootloader unlocking and relocking and providing all required open source code. This is not the same as their software which is invasive spyware.
I agree, it's very convenient to have a phone full of corporate malware. But I thought the point of GrapheneOS was to escape that. My corporate malware only runs on my secure card processor which sits in a pocket glued to my phone.
Well yes, but attacking Graphene for that is attacking the wrong layer. If you want an open payments system the government has to mandate it, or you could take the low chance of success with the free market competition method.
I read the very first message of the thread as "if you're going to regulate something, regulate that we should be able to pay without requiring Google", ie with Graphene and the like. I didn't read it as an attack on Graphene.
IMO the most annoying thing is that Google could solve this problem today by just adding the GrapheneOS signing keys to the whitelisted keys. Instead they decide to exclude GrapheneOS because security, while attesting phones that are still on Android 13 (multiple years without fixes for vulnerabilities that are not marked high/critical) and did not apply ASB patches for up to 12 months.
A first step would be requiring Google to attest all devices that have a locked bootloader, verified boot, signed with non-public keys, and have a recent Android version and patch level.
IMO they should also boot anything older than Android 16 and behind more than 1-2 ASBs, if security is the real reason to have Play Integrity remote attestation.
Seems to be only in the EU (because they're being forced to), and some other sources say google is offsetting the fee through revenue sharing back to the OEMs. In any case the original claim of "the purpose of remote attestation is to force people to buy devices that pay Google license fees" is questionable given that google had to be forced into charging money for it.
The very moment it becomes possible to create a Google Pay alternative, there will be at least a dozen choices, some of them fully open source and privacy conserving.
The only reason why we don’t have them is Google / Apple duopoly.
I seriously doubt that. There used to be more NFC payment apps, but most banks abandoned them since it was cheaper to just pay Google their cut through Google Pay. Or Wallet, or whatever the hell they renamed it to.
Banks letting an open source project run transactions through them... that's... hilarious.
But I thought the point of GrapheneOS was to escape that.
I think the point of GrapheneOS is being as secure as possible first and within those parameters give people the choice how much of Google they want. They have implemented sandboxed Google Play Services for a reason. Many people need Play Services for practical reasons (e.g. because they need to run apps that require it), so let's then run it in the most secure/private way possible - make it a sandboxed app, allowing users to decide whether to install it or not and if they choose to, that they can assign/revoke permissions like any other Android app.
People use alternatives for many different reasons (or multiple at the same time):
- They might want privacy from Google. Using Google Pay probably doesn't make much sense.
- Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US government attack vector.
- They want a clean phone without all kinds of crap like Gemini preinstalled.
- They want to reduce dependence on big tech/Google product in general.
In cases 2-4, using Google Pay with sandboxed Google Play services may be an acceptable compromise for convenience.
Minor note, you forgot battery life. Pinging your location every other minute for traffic and crowd denisty for Google Maps, even using AGPS, isn't cheap.
When you find battery life randomly tanks for a few days, despite not changing anything in your life, it's always Google Play Services that end up being the culprit
Is this an AI response? I get why people want a de-googled phone. What I don't get is why they would want to use tap to pay, one of the payment methods with increased attack vectors.
I hate AI writing, so I never use AI for writing. Randomly throwing in accusations in discussions sucks. I don't think my comment had any of the hallmarks of AI writing either, unless bulleted lists are also not-done these days.
I guess I should be happy that people don't recognize me as a non-native speaker anymore?
I don't follow. If you mean against fraudulent spending phone based tap to pay is probably the most secure. It demands user authentication (biometric or code) for any transaction so there's no real way to trigger a fraudulent spend without the user knowing. Pretty much any other system allows for at least some amount of unauthorized spending if it's stolen.
If you just mean it's less private than I don't really know that it's terribly different than using a card. Especially if the ecosystem were open and you could choose your payment provider and not just have to use Google/apple.
Probably not but you’re doing a bad job explaining what wanting to de-google your phone has to do with the choice of wireless payment methods.
It’s in the name, “de-googling”, not “de-attack-vectoring”. People want to break away from Google specifically. They’ll still use tap to pay because it’s convenient, secure enough, at least as private as any card/bank payment, and ideally not Google, which was what people de-googling want.
> There is significant overlap in that reasoning and not doing tap to pay.
Or using a (smart)phone, right? No need to go to extremes, cutting Google specifically is the win because they centralize the “spying”, not cutting the technology.
You’re stretching this for no good reason and trying to find a connection that doesn’t exist just to save your argument.
Without Google doesn't mean the same thing for everyone. I got a Motorola g moto stylus 2025 and have been running an experiment for almost a year now in which I use this device without ever logging into the device with a Google account. Fdroid and obtainium work flawlessly. Aurora Store works for the most part but some apps won't even let me open them without a play store signed in account which is sad.
Tap to pay apps, if the developer is trustworthy or if it’s from your bank, are significantly more secure than even carrying a physical card around as your payment is now locked behind biometrics/a pin.
You are free to reverse engineer the whole system and find a way to make it work. The world will love you. I suspect there will be a Google hardware attestation at the core of it, but understanding how it works is still huge progress.
That is essentially it as far as my understanding goes.
Google Wallet currently will not run on a fully updated grapheneOS.
Specifically it complains:
"Your device doesn't meet tap to pay security standards. It may be rooted or running uncertified software."
Which is fair. But something that actually works would be nice. I can keep extremely tight control on the NFC stack by toggling NFC with a quick access icon.
Not something I use very often, but not getting locked out of specific, not all, financial rails is one of those things that feels like it rubs up against the perpetual friction that the US founders, framers, whatever; didn't enshrine economic freedom in the same way as speech.
And maybe that's a libertarian fantasy. Idk. Seems worth thinking about for five seconds tho.
Bringing it back to reality. There are an incredible number of issues with trying to set up some kind of a competing service to Google Wallet to the extent that you might as well just go start a bank. And companies like simple have tried that and ended up bought by other banks at the end of it. And they weren't even trying to do anything other than offer people a banking app that wasn't total crap back in the day.
So realistically Google wallet or anything like that is not something I expect to use on a graphene OS phone until the graphene OS Motorola device comes out in the next few years. And that is entirely speculation that services like Google Wallet might be able to work on that device. But honestly it's the only real hope I personally hold for getting access to Modern payment systems on a secure device.
There’s been some progress over at microG, however not fully reverse engineered obviously, and I wouldn’t hold my hopes up for now: https://github.com/microg/GmsCore/issues/361
My bank had NFC payments for years. None of the remote attestation bullshit. I think it used Google's library for doing QR code scans so it wouldn't work without Google Play, but that's beside the point.
Android already supports this, and has supported this for over a decade. The restriction here is on the side of the finance ecosystem. Everyone has congregated on doing Apple/Google Pay because it's cheap and easy to maintain compared to the alternative. Cards companies and banks make deals with Google, just like they do with companies like Apple, Samsung, and Garmin.
Any fintech startup with serious backing can create an Android app that works on any ROM you can imagine. I don't think you'd have an easy time finding investors for this with how much money you need to partake in the ecosystem, but the API is ready for you to implement.
We had that for many years. But banks stopped supporting their own payment solutions because despite not having to pay commission to Google, it was more expensive to support their own solutions.
That should also tell you that almost any open source / non-profit solution is doomed to fail due to costs. What could work is if, just like the UnifiedAttestation initiative has commercial backing, Wero is expanded to also have its own NFC payment stack. The EU already forced Apple to open up NFC, so it is possible to do it for both iOS and Android.
Would it be possible to build something that works at the os level? And is built in the system itself instead of depending on google services ? I mean I don’t think it requires internet access all the time
> They claim first tap to pay will happen later this year.
Big if true. I guess the main problem is, would the banks from all over the world join in?
Fidesmo (https://fidesmo.com/consumer/fidesmo-pay/) has managed to sidestep this by integrating with Curve (https://www.curve.com/), which issues their own card and then charges your bank’s card from their end when you pay with theirs (tokenized and emulated by Fidesmo).
(Fidesmo also integrates with a whole bunch of banks directly, though mainly EU.)
The monopoly/gatekeeping effect of an OS developer making apps that compete with independent apps has such an easy solution. The OS must not give private api's or special permissions to its in-house apps. Don't try to fight the gatekeeping feature by feature, that is whack-a-mole.
Bonus points if you require the primary UI (window manager in the language of the ancients) to be an installable app.
This is a fabulous ruling and the EU continues (for the moment at least) to be the biggest champion of holding corporations to account and pushing back on entrenched tech power.
I know there are bunch of concerning things like chat control getting pushed through but at least there is a counterbalance in other areas as well.
> AI services will be able to easily interact with other apps installed on the device and perform tasks on behalf of the user within those apps, for tasks that the apps and the user have chosen to make available to AI services. These tasks include “send a message”, “create a note”, “schedule a meeting”. This includes access to certain Google apps (i.e.Gmail, Calendar, Drive, Docs, Maps, YouTube, Messages and Phone) that Alphabet will make available through operating system-level integration channels.
> [...]
> For instance, Android implements structured on-device integration through App Functions, which developers can enable for their apps, and which can be accessed by AI services without being reserved anymore for Google services, such as Google Assistant or Gemini.
> 7. Screen automation
> AI services will be able to automate multi-step tasks within apps, on behalf of the user upon their consent. They will do so by imitating user behaviour in a separate virtual window, which makes it possible for the assistant to complete the task in the background, while the user can do something else. [...]
> Android implements screen automation via Computer Control, which can automatically access apps, and which is currently reserved for Google’s services, such as Gemini.
> 9. System-level on-device models
> AI services will be able to call on existing on-device models (“ODMs”), including the Gemini Nano ODMs, that are part of the DMA designated operating system, already preinstalled on Android devices and already made accessible to third parties. As a result of the measures, third-party AI services will have guarantees of equal access (for example, in terms of performance) to ODMs, as Google’s services. [...]
> 10. On-device model implementation
> Third parties will be able to install, run and use on-device models (ODMs) under the same hardware‑resource and background‑execution conditions that Google’s own models enjoy, and will allow their ODMs to be shared centrally with other apps. [...]
Strange page, it keeps repeating that there are 11 features and then lists four or five, thrice over, and all can be summarised as "device access for competitors' AI voice assistants and dependencies thereof". Then there's some FAQ about the timeline and such. At the very bottom is a link to what seems to be the legal details but ends you up on a search page. Unfolding the only result, there is a link to the 'decision text', which of course you can't just read as text but need to get as a PDF download so the lines can't be broken up and the text is super hard to read using, say, an android phone or screen reader. This format ought to die already.
Edit: reading that document, I understand now why that press release, as well as the submission above, doesn't get further than a handful noteworthy properties and that even those partially seem like dependencies of each other: that's all it is. It's all about running code on a device activated by a hotword and the access such that it can actually be used (access to the NPU, ability to run in the background, ability to start phone calls, access to sensors, ability to display things on the screen...)
The core issue is not "Google not allowing a feature", it's that small businesses cannot buy phones, install a patched version of Android without a restriction and sell them to make money.
Until this problem is solved, everything else is palliative.
That was a good read. But I still thought anyone can take graphene os and put it in a phone and sell it? Maybe there is specific licensing restrictions in the android license that stop this.
It's a two-step issue. Manufacturers lock the bootloader and don't provide a method through them to unlock it, therefore making bypassing that "digital lock" in violation of the DMCA.
Some of the ones that seem unlockable are actually not unlockable in practice. Like Xiaomi which provides an unlock option that doesn't work unless you work for Xiaomi.
Ironically, Google's own Pixel line is the only reliable source of phones I know of that's both unlockable and relockable with your own keys. The latter is an important feature that even the "hacker friendly" brands like early OnePlus skipped out on.
Hopefully the hardware vendor GrapheneOS is working with can add a second product line to the list.
Ah, yes, the Google/Apple narrative of "if we open the ecosystem, all users' data is at risk". Meanwhile, they are the companies that continuously harvest behavioral data from phones, put backdoors for law enforcement through weak defaults (iCloud backups are not E2E encrypted, unless you enable ADP), etc. All this while, GrapheneOS, LineageOS, etc. provide real, provable privacy.
"Bootleg" is a meaningless word in this context, so I ignored it. You can't "bootleg" an open-source product; you can only branch it, which is completely legitimate.
I'm arguing against the actual point you made. You made the pedantic argument about "bootlegs" to distract from my argument. Now you've also decided to insult me.
To what end? Do you think that kind of approach convinces anyone?
There is no "fake android," either. Your whole argument is based on two false premises.
I din't make an argument about "bootleg", I just used the term and you argued it.
Besides, depending on the actual OSI license, you can definitely have bootlegs if you really care to argue.
A bootleg does not need to be exploited commercially. It can just be counterfeit.
I am not insulting you. I am telling you that you are being overly pedantic while being wrong at the same time.
You might find this difficult to accept but I'm just calling it.
You are just not making any sense. Your very first comment is the one taking offense with the word 'bootleg' erroneously...
If your worry is about phone-home, no need to mention Android specifically. This happens with all off the shelf phones.
Point is about a phone that has an OS that looks like what you would expect and just doesn't do what you expect.
Obviously you didn't understand what I had written so I had to call you on that. You may feel insulted, does not mean that I am insulting you.
Anyway, just so that it is clear. Probably should end the conversation here so no one feels insulted any further.
It is one of many projects that make alternative, AOSP-based operating systems (e.g. GrapheneOS, LineageOS, /e/OS), and some of them sell devices for an additional source of income (e.g. Murena who develop /e/OS also does this).
The thing is: Google is one of the few Android phone vendors that makes doing so possible at all. Samsung, Nokia, Xiaomi, Oppo, and all the others lock their bootloaders and provide no way to relock them with your own key once you've managed to break them. Google is one of the few (if not only) vendor that actually designs their hardware to permit this. That's how GrapheneOS has blossomed.
When it comes to running patched operating systems, Google's phones are pretty much the only ones that provide a decent option for running secure and user-controlled firmware. It's every other vendor, from Apple to Xiaomi, that's preventing people from doing so.
That said, there are a few companies out there that will happily put your brand and your firmware on their hardware. That's how the Trump Phone was made, the biggest example of this practice in the west. Other utility brands have been releasing cheap crap branded phones for years (like the Gigaset smartphone). You'll need money upfront and a decent minimum order quantity, but getting phones with firmware you control straight from the factory is still an option.
Obviously the Google Play features being available only to Google are a problem, and it's good that the EU is forcing Google to cut the crap, but Google's restrictions aren't the reason companies aren't running custom ROMs. It's pretty much everyone but Google that's at fault for that, from vendors restricting user freedom to app developers restricting their apps to Google Play certified devices only.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can.
Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
The future lies in a large, local-friendly ecosystem and the hardware to support it.
Gate keeping software makes even less sense nowadays.
The competition is on compute offering. Cheaper, faster, at scale. They can have a competitive advantage over incumbents if they stay smart.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can. Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
It is not necessarily a competitive advantage, because Apple needs to do the same (which is why they aren't releasing the new iOS 27 Siri, etc. in the EU).
Apple and Google just took different approaches: Google just released their stuff in violation of the DMA and had the EU come at them. Apple chose to be in compliance before before releasing their assistant updates, though they tried to lobby the EC in favor of releasing now with the promise of adding interoperability in N months.
I am completely in favor of this. But for Google/Apple the best outcome giving their own assistance preferential treatment. More subscription income.
Will be interesting to see how Google implements a more open DSP wake-word detection. The requirement for it to work without the app holding a default role suggests needing to recognize multiple wake-words for each of the non-default apps that uses one.
From an openness perspective this is excellent. Technically it seems challenging with a DSP designed to detect a single thing using as little power as possible. Currently this balances doing as little work as possible to detect plausible utterances of the wake-word on the DSP while minimizing the costs of spurious wake-ups on the CPU. At the very least multiple wake-words seems to need the DSP to do more work and wake up the CPU more often.
What a shame. How much time and €M spent just to deign allow you to do some very specific stuff on their devices (in 5 years at least once the trials and shenanigans settle) ? Obviously it doesn't include the "answering call screening" for example, which requires very privileged APIs accessible only by "system" apps, i.e. the ones preinstalled in the ROM. How about RCS ? Remember RCS the "open" standard replacing SMS ?
RCS is a nothingburger in Europe, virtually everybody uses WhatsApp (and a smaller group also Signal, etc.). RCS is especially relevant to the US where many people use iMessage and the downgrade path is SMS/MMS.
Whoops my bad then, disregard previous post. Creating a facebook account at once with my national id in addition to my carrier subscription. Gotta love US dependency.
WhatsApp accounts aren't linked to Facebook accounts - well, not publicly - I'm sure they know you're the same person on the backend. You only need a phone number to sign up to WhatsApp. If that wasn't the case, it wouldn't be as popular.
RCS is partially open. The protocol is public, as are one or two authentication features. The biggest restriction for custom RCS implementations is that carriers often require access to SIM card functionality to authenticate a phone to their IMS. Only system software (your OS vendor, Google, maybe additional libraries like Facebook in some products) can access those. Unlike SMS, there is no simple "send this string to the modem and you've sent a message" communication method. The entire thing is SIP+RTP+a few other protocols, wrapped up in a brandable package. RCS is as open as SMS has been for a while, perhaps even more open as the SMS stack can only be reliably implemented in IP-only software stacks in LTE+ networks; 3G and below require integrations not even the Android system supports natively.
If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).
When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.
However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.
If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.
Why should I need root or build my own ROM to use an alternative app implementing the whole RCS low level stack ? I sure don't have to do this to change my SMS app (yet). It may be the modem or the OS doing the low level stuff for SMS I don't care, a proper "mobile os" would provide APIs to do it.
Why doesn't the AOSP Messaging app implement it if it's so standard and open ?
https://android.googlesource.com/platform/packages/apps/Mess...
I too would much prefer it if Google were to open-source their messaging app and provide a full RCS API to Android users, but that doesn't change the fact that both the protocol and the underlying OS are open, and others can implement them. Google isn't the Linux Foundation, you shouldn't rely on them to release everything open source and ready to use.
The AOSP messaging app is barebones to say the least, and has been abandoned since the day Google announced Google Messages and its predecessors. Back when that app was still relevant, RCS practically didn't exist.
RCS is not as simple as SMS. You need access to the SIP/RTSP/RTP layer to do video calling, for instance. RCS registration is tied directly to IMS registration, it was never designed to have multiple apps use the protocol at the same time; it does support multi-device setups, as long as all partipants run compatible software. Break that, and you break basic message reception.
Skipping features that go beyond basic messaging entirely, you could probably have some limited RCS support if Google were to take care of all of the internals. You would still need someone to do regular maintenance, like updating protocols to support things like gRPC transports (which landed this month), taking care of the end-to-end encryption, and whatever else comes up in the future. End-to-end encryption in RCS has been in the spec for maybe a year and a half, Android 14 and lower would not be able to use it at all, and Android 15 would miss out on Apple-compatibility as well. Not sure how you would deal with the payment exchange API in such a system, that would need some carrier/bank-run verification scheme.
AOSP's RCS implementation (https://source.android.com/docs/core/connect/ims-single-regi...) was never used by Android's messenger, it only provides very basic functionality: it exists because it has to for basic IMS operations to work, but Google never really bothered with RCS until very recently, long after they stopped maintaining their SMS app.
One could ask the same of other messengers: why can I not access Signal's message database? Why can I not enumerate emails, or query for browsers' search histories? All are built on open technologies, after all.
No, the procedure was specifically against Google Android and the decision document (https://ec.europa.eu/competition/digital_markets_act/cases/2...) is titled "CASE DMA.100220| Alphabet - OS - Google Android - Art. 6(7) - SP - AI". It doesn't mention the existence of other market parties than Alphabet/Google/Android, from what I saw in a quick read-through
It sounds reasonable to apply the same logic to all vendors with similar market power, though. Perhaps this opens the door for an accelerated procedure against Apple as well
Indeed. This ruling seems to be targeted at AI specifically. It is a great ruling, because it allows proper competition of other assistants with Google's (and Bixby). However, IMO the bigger evil is all the anti-competitive stuff that make it impossible for competitors to Android/iOS to enter the market, including European products like SailfishOS, such as remote attestation and the things that flow from it (e.g. no tap-to-pay support with most banks). The EC seems very pre-occupied with competition inside Android/iOS, while completely forgetting about competition between mobile OSes.
It is also pretty jarring to see the EU talk a lot about sovereignty, but then further entrenching the Android/iOS duopoly by baking remote attestation into the EUDI reference wallet (and copied into the national wallets), effectively shutting out alternative systems yet again.
Yes, I know that the EU consists of a lot of bodies and sometimes the right hand doesn't know what the left hand does. But man, sometimes I wish there was a stronger single, long-term vision. Somehow they seem to have forgotten about January this year (Greenland threats) and that as long as we fully depend on Android/iOS, etc. the US could shut down pretty much all modern communication infra. But instead of solving these vulnerabilities now and pouring money into alternatives, we (as the EU) drag ourselves down into battles of just how much we can do on the terrain of some feudal overlords.
It seems like there is a short window where we still have AOSP systems that could be workable for the large population (outside remote attestation, pretty much all apps run on GrapheneOS, microG, etc.) and Google's strong arming through developer verification and remote attestation could still be put back in the box. But the EC does nada, nothing (presumably).
I agree that attestation is the biggest deal. My current hope is that the upcoming GrapheneOS phones will be able to achieve that. It's really up to a manufacturer being able to strong-arm third-parties - banks and such - into accepting their chain of trust, and Motorola may be able to do that.
I don't think the upcoming Motorola phones will change this by themselves. As far as I understand, Motorola will not directly sell GrapheneOS phones. They will make phones that fulfill the hardware requirements and work with the GrapheneOS team to make the firmware available, etc. It will still be up to the user to install GrapheneOS.
That has benefits - you do not have to trust Motorola not to ship stuff that you wouldn't want in the image. They are pristine images that the GrapheneOS project provides. But it also probably doesn't get Motorola in hot water with Google, since they partially do the same as Google does (provide phones with unlocked bootloaders) and what Google used to do (open drivers, device trees, etc.). Plus there are other OEMs that have similar partnerships with other projects (e.g. Fairphone).
into accepting their chain of trust
It's GrapheneOS who will sign the images, not Motorola.
Speaking of Europe, Motorola is probably not big enough here to strong-arm parties. Besides that, I don't think they will do that, since they have to stay in good graces with Google for distributing GMS Android.
I think for Motorola, there are three wins: 1. GrapheneOS has hundreds of thousands of users now, for a smaller OEM capturing some of that market is a significant addition; 2. they want to have a security-focused offering; GrapheneOS can provide that; and 3. they probably want to strengthen their position towards Google. Samsung has their own app store, device finding ecosystem, etc., this tells Google - if you take too much power, we can go our own way. If the Motorola-GrapheneOS experiment is successful, this could provide a similar contingency plan that might hold Google from trying to reign in OEMs too much. This is a real risk for Google - Pixel is so small in terms of marketshare that if, say Samsung, would go on its own, Google Android is pretty much dead.
At any rate, I think Motorola-GrapheneOS can have more of an indirect effect. I think Play Integrity remote attestation will fall if GrapheneOS can quickly get so many users that they become a force to reckon with. In the past, it helped when GrapheneOS users e-mailed an app developer that switched to strong Play Integrity. This will be much more powerful if the GrapheneOS user base grows 10x and more growth is probably possible if there are non-Google devices (especially because part of the potential user base does not want to give a cent to Google).
Getting the EU to ban Play Integrity as-is probably has a much larger chance of succeeding though. This is why I always recommend people to file a DMA complaint/contact the DMA team when some app gets blocked on alternative ROMs due to Play Integrity. The DMA team needs to see/feel that this affects a lot of real people.
Unlikely to happen, it's just not how they operate. Instead they will create a government registry where any legal entity can register their integrity attestation keys, with oversight by a bureaucracy in a process that takes 6 months and €100,000. Apps will be required to use the registry but still allowed to block attestations they don't like, and any attestation key that leaks into open circulation (such as FOSS) will be blacklisted in the registry because it no longer attests anything.
Exactly. There is no actual value provided by attestation that banks actually need. Banks have websites that work in web browsers, and those typically provide 99% of the functionality of the app, and yet the app demands attestation.
GrapheneOS doesn't solve the attestation problem though. If you compile it from source, the attestation still breaks (namely, you have to convince vendors that use attestation to trust your key). In practice, it does not allow you to run your code on your device anymore than stock Android with Google services does. At best, if GrapheneOS' build is reproducible, you can view the source code online and know that there isn't anything else in the blob you load onto your device
Source-available isn't quite the same as having the software freedoms (use, study, modify, share) where you can modify the code or inspect what the various third-party apps are doing on your device. I can currently look into /data/data/any_app and modify preferences, view what telemetry is queued up, remove gigabytes of cache files... all that goes away with a GrapheneOS installation that passes attestation. They want to appear legitimate to app vendors and so comply with Google's rules about what data is accessible to users; otherwise, they'd never convince anyone to add their attestation keys to the allowlist. You need to be on a closed device before those vendors put you on the allow list (and you probably need to sell at least a million devices before they bother to consider you). The concept of attesting your phone is fundamentally antithetical to open source
The US has both infinite money for the rich and strong wealth inequality - both carrot and stick. I don't think it's a good way to live though. China also has unlimited money and top-down economic control that can direct good things to be made. Europe has neither. It has people with stable lives they don't want to mess up, and it has limited money, most of which is claimed by its existing billionaires through its bureaucratic processes.
Phone-tap-to-pay is not a real blocker. In fact I think it should be illegal for all vendors. Just use your physical plastic card. Stick it on the back of your phone if you like.
Phone tap to pay is really handy and provides more security than physical plastic cards. It should just not be used by Apple/Google to block out competitors.
(Yes, I know banking apps can have their own tap-to-pay implementation on Android, but they all standardized on Google Pay because it's less work for them.)
Among many other things, with tap-to-pay you can use a different virtual card for every vendor, so that if it gets misused you can cancel it and know exactly which vendor mishandled it.
It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.
I personally have found great use from the little notifications that graphene OS pops up when the integrity API is accessed and it tells me the application. I saw Instagram accessing the integrity API probably entirely by coincidence while doing something in another app and so Instagram got immediately removed even though I never use it anyway.
feel free to keep your why did you have Instagram on your graphene OS phone to yourself. I know. I know. I know. I know. XD
and a little message when you tap on those notifications is exactly what the parent commenter stated encouraging users to contact app developers so that they can use basic integrity attestation and allow their apps to work on graphene OS.
and some apps do work and use the integrity API. maybe a little too much in my opinion. chatgpt I'm looking at you. my local credit Union's banking app doesn't even bother with the integrity API and they updated their tech stack recently which included app redevelopment.
Stallman was right : without the four freedoms your software owns you rather than vis-a-versa.
Interoperability is the key to breaking out of walled gardens and owning your own data and digital self.
This is a big win but google will fight back it seems instead of embracing interoperability.
It may seem trivial but using a small DSP running a tiny model to provide a battery efficient always on wake up call for home AI is huge.
As a carer for elders who rely on AI to use modern devices in the face of their difficulty keeping up with interface changes this bodes well.
Gatekeeping AI and the future with hidden features is straight out of the bad old days of M$’s embrace, extend and extinguish.
I embraced AI to let my elders control their home and they love being in control but are constantly frustrated with UI changes and often find themselves stuck unable to call me with ‘Alexa call Daniel’ which provides them with hope if they wake stuck in a nightmare.
Come on google, please don’t be evil embrace interoperability and the open source community.
Well done Eff, Cory Doctorow and the Pirate parties of Europe for this small win
I don't care about any of these, I just want to be able to have whatever Google pay does without Google.
You could claim that's not an android problem but if you do I don't think you've ever had to explain to people your phone doesn't have a Google Play store.
blows my mind that there’s not a single open solution for mobile wallets and nobody is saying anything.
"open solution for mobile wallets"
define open wallet then
Because a normal card is superior in most practical cases?
It is? I haven’t carried my wallet around in years, because Apple Wallet does everything I need. Concert tickets, boarding passes, bank cards, public transport cards, etc. A physical wallet and cards in comparison feels like stone age technology.
Banks and card networks will only accept proprietary shitware as payment. Would you rather keep the malware confined to a separate processor chip or would you let it run on your phone?
In other words, would you like to have your physical card to be lost or stolen and someone paying with it? As small amounts don’t ask for a pin confirmation. Having my phone stolen is pretty much another level of attack.
Yes... that $25 if they manage to get even that before it is blocked I can live with. Loosing my phone, even if they can't do anything with it is a whole other scenario. Now I can't even get home.
Your bank will refund any stolen money if your card is stolen.
> would you like to have your physical card to be lost or stolen and someone paying with it?
I don't really care, as I'm protected from fraud by the card issuer and regulations in my country.
> Having my phone stolen is pretty much another level of attack.
Stealing a wallet or a phone seems just about the same level of difficulty.
And you can trick an iPhone into believing you're a transit terminal and charge arbitrary amounts to real credit cards, without unlocking the phone. (And Apple thinks this is a feature.) The attack requires specialized hardware and physical access, but if you've stolen the phone, that's fine.
(Yes, I know, this article is about Android. But most people where I live have iPhones, even if I don't.)
Yes it is. Doesn't break if drop it for one. Much smaller than a phone. Isn't tied to apples ecosystem. etc.
I get that you might want one if you are a tech maximalist with a single focus. But that doesn't mean you should stop carrying your card.
Don't you still have to carry cards for things that aren't digitally excepted, such as a drivers license in most states?
And your battery goes empty, and you just lost everything. Or your phone falls to the ground and breaks.
And to add to payments, the store loyalty apps are the worst... Lidl over here has an app only (no physical loyalty card), and they should be hanged for developing that... first of all, you're waiting in line while a grandma takes her phone out of her purse, then unlock it, and of course android is not satisfied with her fingerprint right then but also wants a pin... then all apps, then scroll down to L, find LidlPlus app, tap on it... QR code? Nope, not yet! First you get a daily coupon wheel of fortune, tap, wait for it to spin, see what your award is... and if it's something that she just bought, she has to manually activate that coupon in the menu (again, tap, find, tap, tap back), and then click the card button to get the qr code to scan... it's literally minutes sometimes of just waiting, instead of scanning a simple qr code on a plastic card pulled from the wallet.
We even had one of our telcos break down (full internet loss, country wide), POS terminals not working at all, and there are actually people with zero cash with them, not even like 50 euros (for just-in-case (like this))... and then you have to wait for them to turn around, take their stuff back and go home hungry.
No it’s not, all of my and my extended family cards (for… like a decade!) are never even leave the envelope they come in. I’m not sure I personally know people who use physical cards over Google or Apple Pay. I have seen the cards being used in the wild, of course. But I’m having hard time remembering anyone I personally know who does that.
How strange that culture is so different in different places. You can just start using them, though. Literally just swipe your card whenever you would swipe your phone.
Do you guys not have wallets with card slots?
So, the argument is that it is popular? I'm not arguing against that...
That people trade anything for even just perceived convenience? That isn't news either, but it does explain a lot of the sad state of affairs we are struggling with today.
You need them in some scenarios. For example, lots of car rental companies refuse to take anything but a physical card.
> I’m not sure I personally know people who use physical cards over Google or Apple Pay.
You live in a pretty weird bubble. (And I live in San Francisco, so I know about weird bubbles.)
I'm starting to come the the same conclusion, but not for practical reasons. My thinking is about privacy. If I buy some chocolates from retailer X (with or without their loyalty system), these parties will know what I purchased and where: The retailer, the bank, the merchant (visa/mc), wallet provider (Google/Apple/Samsung). Any upstream 3rd parties for analytics, big data warehouses, ai companies (fraud detection, spending predictions), marketing companies, research companies, manufacturers. Then there are bluetooth beacons, microphones, cameras, facial recognition, keyboard/screen capture (Gboard, Samsung Keyboard, Whatsapp texts). Then there is sms and popup notification on device that gets ingested by x amount of systems too. So the whole pipe just exists to gather as much as possible data to sell me more stuff. Having a card will take some of them out of the loop or less rich metadata than using a digital wallet.
A card is a good step to reduce that. I want to go farther and pay cash as much as possible, but it's not trivial to manage when all I have is a pocket full of coins. Is there a 3D printed wallet with slots sized for European coins so you can quickly identify and extract the coins you need instead of rummaging through a mixed pocket?
For the Americans: https://www.officedepot.com/a/products/6844022/Nadex-Coins-4...
I assume the same must exist for euros.
You have to negotiate directly with Visa to convince them why they should accept your system. How will you convince them?
We desperately need to break Visa's stranglehold on access to the consumer side of commerce. As long as everyone's only innovating and competing on the merchant side of things, we're not really going to get anywhere.
You're free to make your own card network. How will you convince banks to issue your cards and merchants to accept them?
You mean like the EU digital wallet
You're free to try and make something like that.
They are making something like that as we speak. I’m not sure why though, they’ve had free SEPA Instant transfers for ages now.
Many EU online shops accept SEPA payment. It isn't convenient, because it's a push payment (giro) which means the site can't stick it in the middle of the order flow and expect it to take a few seconds. Some users might have to visit a bank branch to send payment.
Not all banks do SEPA Instant, yeah. I suppose the answer to that is connecting using PSD2 and sending the payment request then checking payment actually went out (using something like https://gocardless.com/). Many countries also have local bank link systems (e.g. in the Baltics it’s common to have dedicated buttons in the payment form for the big 3 or 4 banks everyone uses).
I’m talking about in-person payments though. It would be so easy to implement QR payments backed by the existing SEPA Instant rails. Many bank apps already understand EPC QR codes (usually found on invoices), so shops could just show these to accept payment. In case your bank doesn’t support SEPA Instant, you could show the cashier the receipt in your bank app, which, well, horribly insecure, but probably fine for low-stakes cases like grocery shopping (you don’t want to be banned from your grocery store chain for forging a 35 € payment).
Are you prepared to protect customers by refunding them if they are victims of fraud when using your payment system? Visa and MasterCard are prepared to do that. That's how they could convince consumers to use their cards without worrying.
Clearly consumers do worry, since the ones found in this comment section are saying they refuse to use a card as it could be stolen.
Millions of card transactions are made every day. If consumers worried, they wouldn't have credit or debit cards and they wouldn't use credit or debit cards.
What a single hacker writes is on the other hand just what he wrote.
Millions of people type their banking username and password into services like POLi, too.
so what you're saying is we should be looking at competitors of Visa
MasterCard has the exact same issue.
Yep, the duopoly is pretty strong. There are national card networks (which sometimes make their own tap-to-pay apps!), but if you want universal acceptance you’ve got to deal with the big two.
You can sidestep this however by not dealing with cards. I’d look into various QR payment schemes.
There's Curve Pay which works on GrapheneOS
The whole GrapheneOS thing is a bit of a joke. So you either have to buy google hardware or you run google software.
Anyway, looking forward to the widespread introduction of Wero. Maybe there will be some options for third party roms in the name of digital soveranity. Seems like they want to make the EUDI wallet for digital documents no-google capable for that reason at least.
You think Google puts backdoors in their hardware? They've consistently been one of the most open hardware brands since the start, always allowing bootloader unlocking and relocking and providing all required open source code. This is not the same as their software which is invasive spyware.
What cards & banks does it work with these days? Last time I checked, it wasn't really a serious alternative.
Google should've been broken up eons ago.
Why would anyone who cares enough about security/privacy to run a de-googled phone want to use a tap to pay app?
Because it’s convenient?
I agree, it's very convenient to have a phone full of corporate malware. But I thought the point of GrapheneOS was to escape that. My corporate malware only runs on my secure card processor which sits in a pocket glued to my phone.
You're begging the question. The entire premise of this thread is "we should be able to pay without infesting our phone with corporate malware".
Well yes, but attacking Graphene for that is attacking the wrong layer. If you want an open payments system the government has to mandate it, or you could take the low chance of success with the free market competition method.
I read the very first message of the thread as "if you're going to regulate something, regulate that we should be able to pay without requiring Google", ie with Graphene and the like. I didn't read it as an attack on Graphene.
IMO the most annoying thing is that Google could solve this problem today by just adding the GrapheneOS signing keys to the whitelisted keys. Instead they decide to exclude GrapheneOS because security, while attesting phones that are still on Android 13 (multiple years without fixes for vulnerabilities that are not marked high/critical) and did not apply ASB patches for up to 12 months.
A first step would be requiring Google to attest all devices that have a locked bootloader, verified boot, signed with non-public keys, and have a recent Android version and patch level.
IMO they should also boot anything older than Android 16 and behind more than 1-2 ASBs, if security is the real reason to have Play Integrity remote attestation.
POSIWID: the purpose of remote attestation is to force people to buy devices that pay Google license fees.
>that pay Google license fees
Source? I thought it was free for OEMs?
I think there's a fee and also a long list of requirements - such as you must not sell any phone without Google Play Store.
>I think there's a fee
Seems to be only in the EU (because they're being forced to), and some other sources say google is offsetting the fee through revenue sharing back to the OEMs. In any case the original claim of "the purpose of remote attestation is to force people to buy devices that pay Google license fees" is questionable given that google had to be forced into charging money for it.
https://www.theverge.com/2018/10/19/17999366/google-eu-andro...
The very moment it becomes possible to create a Google Pay alternative, there will be at least a dozen choices, some of them fully open source and privacy conserving.
The only reason why we don’t have them is Google / Apple duopoly.
It's possible right now, but you have to (as Google did) convince all banks, merchants, and card networks to let them use your system.
Merchants and card networks don't need to be convinced. From their PoV Google Pay device is just a regular payment card.
I seriously doubt that. There used to be more NFC payment apps, but most banks abandoned them since it was cheaper to just pay Google their cut through Google Pay. Or Wallet, or whatever the hell they renamed it to.
Banks letting an open source project run transactions through them... that's... hilarious.
But I thought the point of GrapheneOS was to escape that.
I think the point of GrapheneOS is being as secure as possible first and within those parameters give people the choice how much of Google they want. They have implemented sandboxed Google Play Services for a reason. Many people need Play Services for practical reasons (e.g. because they need to run apps that require it), so let's then run it in the most secure/private way possible - make it a sandboxed app, allowing users to decide whether to install it or not and if they choose to, that they can assign/revoke permissions like any other Android app.
Some people like to have choices other than "all" and "nothing"
People use alternatives for many different reasons (or multiple at the same time):
- They might want privacy from Google. Using Google Pay probably doesn't make much sense.
- Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US government attack vector.
- They want a clean phone without all kinds of crap like Gemini preinstalled.
- They want to reduce dependence on big tech/Google product in general.
In cases 2-4, using Google Pay with sandboxed Google Play services may be an acceptable compromise for convenience.
Minor note, you forgot battery life. Pinging your location every other minute for traffic and crowd denisty for Google Maps, even using AGPS, isn't cheap.
When you find battery life randomly tanks for a few days, despite not changing anything in your life, it's always Google Play Services that end up being the culprit
Great point! For me that was not a reason to get a phone with GrapheneOS, but definitely a noticeable/welcome side-effect.
Is this an AI response? I get why people want a de-googled phone. What I don't get is why they would want to use tap to pay, one of the payment methods with increased attack vectors.
Is this an AI response?
No.
I hate AI writing, so I never use AI for writing. Randomly throwing in accusations in discussions sucks. I don't think my comment had any of the hallmarks of AI writing either, unless bulleted lists are also not-done these days.
I guess I should be happy that people don't recognize me as a non-native speaker anymore?
Nah, some people are just having too much !fun! witch-hunting.
The accusation was not random. That writing had an AI tone to it with the bulleting etc, and didn't address the actual point being questioned.
> with increased attack vectors.
I don't follow. If you mean against fraudulent spending phone based tap to pay is probably the most secure. It demands user authentication (biometric or code) for any transaction so there's no real way to trigger a fraudulent spend without the user knowing. Pretty much any other system allows for at least some amount of unauthorized spending if it's stolen.
If you just mean it's less private than I don't really know that it's terribly different than using a card. Especially if the ecosystem were open and you could choose your payment provider and not just have to use Google/apple.
You might want to look into NGate.
> Is this an AI response?
Probably not but you’re doing a bad job explaining what wanting to de-google your phone has to do with the choice of wireless payment methods.
It’s in the name, “de-googling”, not “de-attack-vectoring”. People want to break away from Google specifically. They’ll still use tap to pay because it’s convenient, secure enough, at least as private as any card/bank payment, and ideally not Google, which was what people de-googling want.
Well, why do people want to de-google? Likely peivacy and security. There is significant overlap in that reasoning and not doing tap to pay.
> There is significant overlap in that reasoning and not doing tap to pay.
Or using a (smart)phone, right? No need to go to extremes, cutting Google specifically is the win because they centralize the “spying”, not cutting the technology.
You’re stretching this for no good reason and trying to find a connection that doesn’t exist just to save your argument.
Without Google doesn't mean the same thing for everyone. I got a Motorola g moto stylus 2025 and have been running an experiment for almost a year now in which I use this device without ever logging into the device with a Google account. Fdroid and obtainium work flawlessly. Aurora Store works for the most part but some apps won't even let me open them without a play store signed in account which is sad.
Why can't I use my bank's app, which I presumably already trust, to tap-to-pay? Why should there be a third party involved at all?
Because people have different priorities than you do, and just because you can't imagine something, it doesn't mean it's not real or reasonable.
Well it's going to be a matter of time anyway, I'm already forced to use an app when I'd rather not.
But more than that I want to have a choice.
Because tap to pay has nothing to do with Google?
Some people just want a phone without the duopoly and nothing else.
Tap to pay apps, if the developer is trustworthy or if it’s from your bank, are significantly more secure than even carrying a physical card around as your payment is now locked behind biometrics/a pin.
Also de-googling isn’t the point of GrapheneOS.
How about a way to use contactless payments on, say, a Pebble watch?
Xiaomi Mi Band 6 and 7 support NFC card emulation for payments, issued by Visa/MC.
You are free to reverse engineer the whole system and find a way to make it work. The world will love you. I suspect there will be a Google hardware attestation at the core of it, but understanding how it works is still huge progress.
That is essentially it as far as my understanding goes.
Google Wallet currently will not run on a fully updated grapheneOS.
Specifically it complains:
"Your device doesn't meet tap to pay security standards. It may be rooted or running uncertified software."
Which is fair. But something that actually works would be nice. I can keep extremely tight control on the NFC stack by toggling NFC with a quick access icon.
Not something I use very often, but not getting locked out of specific, not all, financial rails is one of those things that feels like it rubs up against the perpetual friction that the US founders, framers, whatever; didn't enshrine economic freedom in the same way as speech.
And maybe that's a libertarian fantasy. Idk. Seems worth thinking about for five seconds tho.
Bringing it back to reality. There are an incredible number of issues with trying to set up some kind of a competing service to Google Wallet to the extent that you might as well just go start a bank. And companies like simple have tried that and ended up bought by other banks at the end of it. And they weren't even trying to do anything other than offer people a banking app that wasn't total crap back in the day.
So realistically Google wallet or anything like that is not something I expect to use on a graphene OS phone until the graphene OS Motorola device comes out in the next few years. And that is entirely speculation that services like Google Wallet might be able to work on that device. But honestly it's the only real hope I personally hold for getting access to Modern payment systems on a secure device.
There’s been some progress over at microG, however not fully reverse engineered obviously, and I wouldn’t hold my hopes up for now: https://github.com/microg/GmsCore/issues/361
A phone case with your NFC credit card in a pocket on the back. Boom, problem solved.
This is a great solution if you have the physical card. One very nice use case of Google/Apple Pay is being able to pay with a virtual card in-person.
My bank had NFC payments for years. None of the remote attestation bullshit. I think it used Google's library for doing QR code scans so it wouldn't work without Google Play, but that's beside the point.
Android already supports this, and has supported this for over a decade. The restriction here is on the side of the finance ecosystem. Everyone has congregated on doing Apple/Google Pay because it's cheap and easy to maintain compared to the alternative. Cards companies and banks make deals with Google, just like they do with companies like Apple, Samsung, and Garmin.
Any fintech startup with serious backing can create an Android app that works on any ROM you can imagine. I don't think you'd have an easy time finding investors for this with how much money you need to partake in the ecosystem, but the API is ready for you to implement.
We had that for many years. But banks stopped supporting their own payment solutions because despite not having to pay commission to Google, it was more expensive to support their own solutions.
That should also tell you that almost any open source / non-profit solution is doomed to fail due to costs. What could work is if, just like the UnifiedAttestation initiative has commercial backing, Wero is expanded to also have its own NFC payment stack. The EU already forced Apple to open up NFC, so it is possible to do it for both iOS and Android.
Would it be possible to build something that works at the os level? And is built in the system itself instead of depending on google services ? I mean I don’t think it requires internet access all the time
Yes, Russian MIR system works this way.
https://glenbrook.com/payments_news/russias-mir-domestic-pay...
Just an application which emulates the card over NFC. No need to Google Play Services. It's been this way for ≈10 years I guess.
Walt https://walt.is/ is building exactly that in Europe. They claim first tap to pay will happen later this year.
Some European banks including mine offer NFC payments via their app as well. You don't need Google services.
> offer NFC payments via their app
NAB here in Australia did previously as well, but then they stopped doing that in 2022.
https://www.zdnet.com/finance/banking/nab-waves-goodbye-to-n...
> They claim first tap to pay will happen later this year.
Big if true. I guess the main problem is, would the banks from all over the world join in?
Fidesmo (https://fidesmo.com/consumer/fidesmo-pay/) has managed to sidestep this by integrating with Curve (https://www.curve.com/), which issues their own card and then charges your bank’s card from their end when you pay with theirs (tokenized and emulated by Fidesmo).
(Fidesmo also integrates with a whole bunch of banks directly, though mainly EU.)
The monopoly/gatekeeping effect of an OS developer making apps that compete with independent apps has such an easy solution. The OS must not give private api's or special permissions to its in-house apps. Don't try to fight the gatekeeping feature by feature, that is whack-a-mole.
Bonus points if you require the primary UI (window manager in the language of the ancients) to be an installable app.
Then the OS developer will simply make these "apps" part of the OS.
This is a fabulous ruling and the EU continues (for the moment at least) to be the biggest champion of holding corporations to account and pushing back on entrenched tech power. I know there are bunch of concerning things like chat control getting pushed through but at least there is a counterbalance in other areas as well.
Very nice, here are the 11 Android features that must be made accessible to third party's: https://digital-markets-act.ec.europa.eu/developer-portal/in...
My favorites:
> 6. Structured on-device integration
> AI services will be able to easily interact with other apps installed on the device and perform tasks on behalf of the user within those apps, for tasks that the apps and the user have chosen to make available to AI services. These tasks include “send a message”, “create a note”, “schedule a meeting”. This includes access to certain Google apps (i.e.Gmail, Calendar, Drive, Docs, Maps, YouTube, Messages and Phone) that Alphabet will make available through operating system-level integration channels.
> [...]
> For instance, Android implements structured on-device integration through App Functions, which developers can enable for their apps, and which can be accessed by AI services without being reserved anymore for Google services, such as Google Assistant or Gemini.
> 7. Screen automation
> AI services will be able to automate multi-step tasks within apps, on behalf of the user upon their consent. They will do so by imitating user behaviour in a separate virtual window, which makes it possible for the assistant to complete the task in the background, while the user can do something else. [...]
> Android implements screen automation via Computer Control, which can automatically access apps, and which is currently reserved for Google’s services, such as Gemini.
> 9. System-level on-device models
> AI services will be able to call on existing on-device models (“ODMs”), including the Gemini Nano ODMs, that are part of the DMA designated operating system, already preinstalled on Android devices and already made accessible to third parties. As a result of the measures, third-party AI services will have guarantees of equal access (for example, in terms of performance) to ODMs, as Google’s services. [...]
> 10. On-device model implementation
> Third parties will be able to install, run and use on-device models (ODMs) under the same hardware‑resource and background‑execution conditions that Google’s own models enjoy, and will allow their ODMs to be shared centrally with other apps. [...]
Strange page, it keeps repeating that there are 11 features and then lists four or five, thrice over, and all can be summarised as "device access for competitors' AI voice assistants and dependencies thereof". Then there's some FAQ about the timeline and such. At the very bottom is a link to what seems to be the legal details but ends you up on a search page. Unfolding the only result, there is a link to the 'decision text', which of course you can't just read as text but need to get as a PDF download so the lines can't be broken up and the text is super hard to read using, say, an android phone or screen reader. This format ought to die already.
Anyway, the actual decision text: https://ec.europa.eu/competition/digital_markets_act/cases/2...
Edit: reading that document, I understand now why that press release, as well as the submission above, doesn't get further than a handful noteworthy properties and that even those partially seem like dependencies of each other: that's all it is. It's all about running code on a device activated by a hotword and the access such that it can actually be used (access to the NPU, ability to run in the background, ability to start phone calls, access to sensors, ability to display things on the screen...)
This is all smoke and mirrors.
The core issue is not "Google not allowing a feature", it's that small businesses cannot buy phones, install a patched version of Android without a restriction and sell them to make money.
Until this problem is solved, everything else is palliative.
What prevents this? I always assumed they could.
https://www.theguardian.com/commentisfree/2026/jan/10/trump-...
DMCA and other anti-circumvention regulations.
That was a good read. But I still thought anyone can take graphene os and put it in a phone and sell it? Maybe there is specific licensing restrictions in the android license that stop this.
It's a two-step issue. Manufacturers lock the bootloader and don't provide a method through them to unlock it, therefore making bypassing that "digital lock" in violation of the DMCA.
Bootloaders are locked and most of them are unlockable.
Most of them are *not unlockable.
Some of the ones that seem unlockable are actually not unlockable in practice. Like Xiaomi which provides an unlock option that doesn't work unless you work for Xiaomi.
Ironically, Google's own Pixel line is the only reliable source of phones I know of that's both unlockable and relockable with your own keys. The latter is an important feature that even the "hacker friendly" brands like early OnePlus skipped out on.
Hopefully the hardware vendor GrapheneOS is working with can add a second product line to the list.
> it's that small businesses cannot buy phones, install a patched version of Android without a restriction
Pardon my ignorance; but why would Android need to be patched? Is it because it wouldn't run on the phone hardware otherwise?
>Is it because it wouldn't run on the phone hardware otherwise?
Because those 11 features mentioned in the OP post need to be unlocked.
Who wants a bootleg Android that sends all your call logs who knows where? xD
Emm.. as if Samsung doesn't..?
Ah, yes, the Google/Apple narrative of "if we open the ecosystem, all users' data is at risk". Meanwhile, they are the companies that continuously harvest behavioral data from phones, put backdoors for law enforcement through weak defaults (iCloud backups are not E2E encrypted, unless you enable ADP), etc. All this while, GrapheneOS, LineageOS, etc. provide real, provable privacy.
Please stop parroting surveillance tech company's narratives.
You didn't get it. I'm talking about fake Android. Not GrapheneOS or similarly a whole other OS that doesn't try to pass as Android.
Everyone who buys an Android phone. This is about the opposite, an option to buy a phone that does not do that.
I said bootleg Android didnt I? Are Android phones using mods or a complete revamped version?
"Bootleg" is a meaningless word in this context, so I ignored it. You can't "bootleg" an open-source product; you can only branch it, which is completely legitimate.
So pedantic, you must be fun at parties. Or maybe are you arguing for the sake of arguing? Fake Android if it suits you better.
I'm arguing against the actual point you made. You made the pedantic argument about "bootlegs" to distract from my argument. Now you've also decided to insult me.
To what end? Do you think that kind of approach convinces anyone?
There is no "fake android," either. Your whole argument is based on two false premises.
I din't make an argument about "bootleg", I just used the term and you argued it.
Besides, depending on the actual OSI license, you can definitely have bootlegs if you really care to argue.
A bootleg does not need to be exploited commercially. It can just be counterfeit.
I am not insulting you. I am telling you that you are being overly pedantic while being wrong at the same time. You might find this difficult to accept but I'm just calling it.
You started arguing about it:
> I said bootleg Android didnt I?
And you're still doing it. Just let it go. It doesn't matter, your argument is wrong either way.
Also, please stop insulting me.
You are just not making any sense. Your very first comment is the one taking offense with the word 'bootleg' erroneously...
If your worry is about phone-home, no need to mention Android specifically. This happens with all off the shelf phones. Point is about a phone that has an OS that looks like what you would expect and just doesn't do what you expect. Obviously you didn't understand what I had written so I had to call you on that. You may feel insulted, does not mean that I am insulting you.
Anyway, just so that it is clear. Probably should end the conversation here so no one feels insulted any further.
I recently learned that there is a business doing exactly that:
https://iode.tech/
I don't think it's high volume, I think this is done by some of the microg folks.
But OEMs probably do everything in their power to make this business model unviable or at least not scale.
It is one of many projects that make alternative, AOSP-based operating systems (e.g. GrapheneOS, LineageOS, /e/OS), and some of them sell devices for an additional source of income (e.g. Murena who develop /e/OS also does this).
The thing is: Google is one of the few Android phone vendors that makes doing so possible at all. Samsung, Nokia, Xiaomi, Oppo, and all the others lock their bootloaders and provide no way to relock them with your own key once you've managed to break them. Google is one of the few (if not only) vendor that actually designs their hardware to permit this. That's how GrapheneOS has blossomed.
When it comes to running patched operating systems, Google's phones are pretty much the only ones that provide a decent option for running secure and user-controlled firmware. It's every other vendor, from Apple to Xiaomi, that's preventing people from doing so.
That said, there are a few companies out there that will happily put your brand and your firmware on their hardware. That's how the Trump Phone was made, the biggest example of this practice in the west. Other utility brands have been releasing cheap crap branded phones for years (like the Gigaset smartphone). You'll need money upfront and a decent minimum order quantity, but getting phones with firmware you control straight from the factory is still an option.
Obviously the Google Play features being available only to Google are a problem, and it's good that the EU is forcing Google to cut the crap, but Google's restrictions aren't the reason companies aren't running custom ROMs. It's pretty much everyone but Google that's at fault for that, from vendors restricting user freedom to app developers restricting their apps to Google Play certified devices only.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can. Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
The future lies in a large, local-friendly ecosystem and the hardware to support it.
Gate keeping software makes even less sense nowadays.
The competition is on compute offering. Cheaper, faster, at scale. They can have a competitive advantage over incumbents if they stay smart.
Exactly, this ruling makes Android stronger.
Funnily enough, I think it is in Google's best interest to comply and do the best work they can. Besides security that they might want to guarantee up to a limit, that would boost Android usage, also including their own hardware.
It is not necessarily a competitive advantage, because Apple needs to do the same (which is why they aren't releasing the new iOS 27 Siri, etc. in the EU).
Apple and Google just took different approaches: Google just released their stuff in violation of the DMA and had the EU come at them. Apple chose to be in compliance before before releasing their assistant updates, though they tried to lobby the EC in favor of releasing now with the promise of adding interoperability in N months.
I am completely in favor of this. But for Google/Apple the best outcome giving their own assistance preferential treatment. More subscription income.
Is this ruling related to https://keepandroidopen.org/ at all? It's not clear to me..
Unrelated
Will be interesting to see how Google implements a more open DSP wake-word detection. The requirement for it to work without the app holding a default role suggests needing to recognize multiple wake-words for each of the non-default apps that uses one.
From an openness perspective this is excellent. Technically it seems challenging with a DSP designed to detect a single thing using as little power as possible. Currently this balances doing as little work as possible to detect plausible utterances of the wake-word on the DSP while minimizing the costs of spurious wake-ups on the CPU. At the very least multiple wake-words seems to need the DSP to do more work and wake up the CPU more often.
What a shame. How much time and €M spent just to deign allow you to do some very specific stuff on their devices (in 5 years at least once the trials and shenanigans settle) ? Obviously it doesn't include the "answering call screening" for example, which requires very privileged APIs accessible only by "system" apps, i.e. the ones preinstalled in the ROM. How about RCS ? Remember RCS the "open" standard replacing SMS ?
RCS is a nothingburger in Europe, virtually everybody uses WhatsApp (and a smaller group also Signal, etc.). RCS is especially relevant to the US where many people use iMessage and the downgrade path is SMS/MMS.
Whoops my bad then, disregard previous post. Creating a facebook account at once with my national id in addition to my carrier subscription. Gotta love US dependency.
WhatsApp accounts aren't linked to Facebook accounts - well, not publicly - I'm sure they know you're the same person on the backend. You only need a phone number to sign up to WhatsApp. If that wasn't the case, it wouldn't be as popular.
RCS is partially open. The protocol is public, as are one or two authentication features. The biggest restriction for custom RCS implementations is that carriers often require access to SIM card functionality to authenticate a phone to their IMS. Only system software (your OS vendor, Google, maybe additional libraries like Facebook in some products) can access those. Unlike SMS, there is no simple "send this string to the modem and you've sent a message" communication method. The entire thing is SIP+RTP+a few other protocols, wrapped up in a brandable package. RCS is as open as SMS has been for a while, perhaps even more open as the SMS stack can only be reliably implemented in IP-only software stacks in LTE+ networks; 3G and below require integrations not even the Android system supports natively.
If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).
When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.
However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.
If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.
Why should I need root or build my own ROM to use an alternative app implementing the whole RCS low level stack ? I sure don't have to do this to change my SMS app (yet). It may be the modem or the OS doing the low level stuff for SMS I don't care, a proper "mobile os" would provide APIs to do it. Why doesn't the AOSP Messaging app implement it if it's so standard and open ? https://android.googlesource.com/platform/packages/apps/Mess...
I too would much prefer it if Google were to open-source their messaging app and provide a full RCS API to Android users, but that doesn't change the fact that both the protocol and the underlying OS are open, and others can implement them. Google isn't the Linux Foundation, you shouldn't rely on them to release everything open source and ready to use.
The AOSP messaging app is barebones to say the least, and has been abandoned since the day Google announced Google Messages and its predecessors. Back when that app was still relevant, RCS practically didn't exist.
RCS is not as simple as SMS. You need access to the SIP/RTSP/RTP layer to do video calling, for instance. RCS registration is tied directly to IMS registration, it was never designed to have multiple apps use the protocol at the same time; it does support multi-device setups, as long as all partipants run compatible software. Break that, and you break basic message reception.
Skipping features that go beyond basic messaging entirely, you could probably have some limited RCS support if Google were to take care of all of the internals. You would still need someone to do regular maintenance, like updating protocols to support things like gRPC transports (which landed this month), taking care of the end-to-end encryption, and whatever else comes up in the future. End-to-end encryption in RCS has been in the spec for maybe a year and a half, Android 14 and lower would not be able to use it at all, and Android 15 would miss out on Apple-compatibility as well. Not sure how you would deal with the payment exchange API in such a system, that would need some carrier/bank-run verification scheme.
AOSP's RCS implementation (https://source.android.com/docs/core/connect/ims-single-regi...) was never used by Android's messenger, it only provides very basic functionality: it exists because it has to for basic IMS operations to work, but Google never really bothered with RCS until very recently, long after they stopped maintaining their SMS app.
One could ask the same of other messengers: why can I not access Signal's message database? Why can I not enumerate emails, or query for browsers' search histories? All are built on open technologies, after all.
Does this apply to Apple to have something separate to Siri in iOS?
No, the procedure was specifically against Google Android and the decision document (https://ec.europa.eu/competition/digital_markets_act/cases/2...) is titled "CASE DMA.100220| Alphabet - OS - Google Android - Art. 6(7) - SP - AI". It doesn't mention the existence of other market parties than Alphabet/Google/Android, from what I saw in a quick read-through
It sounds reasonable to apply the same logic to all vendors with similar market power, though. Perhaps this opens the door for an accelerated procedure against Apple as well
So they are gonna add these to AOSP?
Obviously no, it will be another API in Google Mobile Services and you'll have to register to them to be allowed to use it.
I wonder what happened to the laws the limited market monopoly and trust
Now if only these rulings also covered attestation.
Indeed. This ruling seems to be targeted at AI specifically. It is a great ruling, because it allows proper competition of other assistants with Google's (and Bixby). However, IMO the bigger evil is all the anti-competitive stuff that make it impossible for competitors to Android/iOS to enter the market, including European products like SailfishOS, such as remote attestation and the things that flow from it (e.g. no tap-to-pay support with most banks). The EC seems very pre-occupied with competition inside Android/iOS, while completely forgetting about competition between mobile OSes.
It is also pretty jarring to see the EU talk a lot about sovereignty, but then further entrenching the Android/iOS duopoly by baking remote attestation into the EUDI reference wallet (and copied into the national wallets), effectively shutting out alternative systems yet again.
Yes, I know that the EU consists of a lot of bodies and sometimes the right hand doesn't know what the left hand does. But man, sometimes I wish there was a stronger single, long-term vision. Somehow they seem to have forgotten about January this year (Greenland threats) and that as long as we fully depend on Android/iOS, etc. the US could shut down pretty much all modern communication infra. But instead of solving these vulnerabilities now and pouring money into alternatives, we (as the EU) drag ourselves down into battles of just how much we can do on the terrain of some feudal overlords.
It seems like there is a short window where we still have AOSP systems that could be workable for the large population (outside remote attestation, pretty much all apps run on GrapheneOS, microG, etc.) and Google's strong arming through developer verification and remote attestation could still be put back in the box. But the EC does nada, nothing (presumably).
I agree that attestation is the biggest deal. My current hope is that the upcoming GrapheneOS phones will be able to achieve that. It's really up to a manufacturer being able to strong-arm third-parties - banks and such - into accepting their chain of trust, and Motorola may be able to do that.
I don't think the upcoming Motorola phones will change this by themselves. As far as I understand, Motorola will not directly sell GrapheneOS phones. They will make phones that fulfill the hardware requirements and work with the GrapheneOS team to make the firmware available, etc. It will still be up to the user to install GrapheneOS.
That has benefits - you do not have to trust Motorola not to ship stuff that you wouldn't want in the image. They are pristine images that the GrapheneOS project provides. But it also probably doesn't get Motorola in hot water with Google, since they partially do the same as Google does (provide phones with unlocked bootloaders) and what Google used to do (open drivers, device trees, etc.). Plus there are other OEMs that have similar partnerships with other projects (e.g. Fairphone).
into accepting their chain of trust
It's GrapheneOS who will sign the images, not Motorola.
Speaking of Europe, Motorola is probably not big enough here to strong-arm parties. Besides that, I don't think they will do that, since they have to stay in good graces with Google for distributing GMS Android.
I think for Motorola, there are three wins: 1. GrapheneOS has hundreds of thousands of users now, for a smaller OEM capturing some of that market is a significant addition; 2. they want to have a security-focused offering; GrapheneOS can provide that; and 3. they probably want to strengthen their position towards Google. Samsung has their own app store, device finding ecosystem, etc., this tells Google - if you take too much power, we can go our own way. If the Motorola-GrapheneOS experiment is successful, this could provide a similar contingency plan that might hold Google from trying to reign in OEMs too much. This is a real risk for Google - Pixel is so small in terms of marketshare that if, say Samsung, would go on its own, Google Android is pretty much dead.
At any rate, I think Motorola-GrapheneOS can have more of an indirect effect. I think Play Integrity remote attestation will fall if GrapheneOS can quickly get so many users that they become a force to reckon with. In the past, it helped when GrapheneOS users e-mailed an app developer that switched to strong Play Integrity. This will be much more powerful if the GrapheneOS user base grows 10x and more growth is probably possible if there are non-Google devices (especially because part of the potential user base does not want to give a cent to Google).
Getting the EU to ban Play Integrity as-is probably has a much larger chance of succeeding though. This is why I always recommend people to file a DMA complaint/contact the DMA team when some app gets blocked on alternative ROMs due to Play Integrity. The DMA team needs to see/feel that this affects a lot of real people.
> Getting the EU to ban Play Integrity
Unlikely to happen, it's just not how they operate. Instead they will create a government registry where any legal entity can register their integrity attestation keys, with oversight by a bureaucracy in a process that takes 6 months and €100,000. Apps will be required to use the registry but still allowed to block attestations they don't like, and any attestation key that leaks into open circulation (such as FOSS) will be blacklisted in the registry because it no longer attests anything.
any legal entity can register their integrity attestation keys, with oversight by a bureaucracy in a process that takes 6 months and €100,000
That wouldn't be great, but at the same time an improvement over the current situation.
attestation key that leaks into open circulation (such as FOSS) will be blacklisted in the registry because it no longer attests anything
Which makes sense if remote attestation is what you want.
Yes. It makes sense for well-regulated remote attestation. But is that what we actually want or do we want to destroy the concept altogether?
Exactly. There is no actual value provided by attestation that banks actually need. Banks have websites that work in web browsers, and those typically provide 99% of the functionality of the app, and yet the app demands attestation.
GrapheneOS doesn't solve the attestation problem though. If you compile it from source, the attestation still breaks (namely, you have to convince vendors that use attestation to trust your key). In practice, it does not allow you to run your code on your device anymore than stock Android with Google services does. At best, if GrapheneOS' build is reproducible, you can view the source code online and know that there isn't anything else in the blob you load onto your device
Source-available isn't quite the same as having the software freedoms (use, study, modify, share) where you can modify the code or inspect what the various third-party apps are doing on your device. I can currently look into /data/data/any_app and modify preferences, view what telemetry is queued up, remove gigabytes of cache files... all that goes away with a GrapheneOS installation that passes attestation. They want to appear legitimate to app vendors and so comply with Google's rules about what data is accessible to users; otherwise, they'd never convince anyone to add their attestation keys to the allowlist. You need to be on a closed device before those vendors put you on the allow list (and you probably need to sell at least a million devices before they bother to consider you). The concept of attesting your phone is fundamentally antithetical to open source
I mean EU have 20 years to make android/ios competition and they aren't able to replicate it so its them to blame
also they should not abandon Nokia back then
The US has both infinite money for the rich and strong wealth inequality - both carrot and stick. I don't think it's a good way to live though. China also has unlimited money and top-down economic control that can direct good things to be made. Europe has neither. It has people with stable lives they don't want to mess up, and it has limited money, most of which is claimed by its existing billionaires through its bureaucratic processes.
You know that this is cope of Incompetent of European Homegrown software industry right ???
China literally backwater in 1970s, now they have some of the biggest software tech itw
there is no excuse
I literally just told you why.
"China has top-down economic control that can direct good things to be made."
so European Union didn't exist ??? this is literally just an excuse
The European Union doesn't top-down control the economy of Europe...
so you just want to get run over ????
like wtf is this answer, its like y'all give up from starting point
Phone-tap-to-pay is not a real blocker. In fact I think it should be illegal for all vendors. Just use your physical plastic card. Stick it on the back of your phone if you like.
Phone tap to pay is really handy and provides more security than physical plastic cards. It should just not be used by Apple/Google to block out competitors.
(Yes, I know banking apps can have their own tap-to-pay implementation on Android, but they all standardized on Google Pay because it's less work for them.)
How so?
Among many other things, with tap-to-pay you can use a different virtual card for every vendor, so that if it gets misused you can cancel it and know exactly which vendor mishandled it.
Android has an accessible hardware attestation API already (https://developer.android.com/privacy-and-security/security-...). It's what powers the attestation API that GrapheneOS made as an alternative to Play Integrity and friends (demo app: https://github.com/GrapheneOS/Auditor)
It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.
I personally have found great use from the little notifications that graphene OS pops up when the integrity API is accessed and it tells me the application. I saw Instagram accessing the integrity API probably entirely by coincidence while doing something in another app and so Instagram got immediately removed even though I never use it anyway.
feel free to keep your why did you have Instagram on your graphene OS phone to yourself. I know. I know. I know. I know. XD
and a little message when you tap on those notifications is exactly what the parent commenter stated encouraging users to contact app developers so that they can use basic integrity attestation and allow their apps to work on graphene OS.
and some apps do work and use the integrity API. maybe a little too much in my opinion. chatgpt I'm looking at you. my local credit Union's banking app doesn't even bother with the integrity API and they updated their tech stack recently which included app redevelopment.
Stallman was right : without the four freedoms your software owns you rather than vis-a-versa.
Interoperability is the key to breaking out of walled gardens and owning your own data and digital self.
This is a big win but google will fight back it seems instead of embracing interoperability.
It may seem trivial but using a small DSP running a tiny model to provide a battery efficient always on wake up call for home AI is huge.
As a carer for elders who rely on AI to use modern devices in the face of their difficulty keeping up with interface changes this bodes well.
Gatekeeping AI and the future with hidden features is straight out of the bad old days of M$’s embrace, extend and extinguish.
I embraced AI to let my elders control their home and they love being in control but are constantly frustrated with UI changes and often find themselves stuck unable to call me with ‘Alexa call Daniel’ which provides them with hope if they wake stuck in a nightmare.
Come on google, please don’t be evil embrace interoperability and the open source community.
Well done Eff, Cory Doctorow and the Pirate parties of Europe for this small win
Excellent, now please force them to open up app installation again!
Now let's bite the apple.
Is "in the EU" the new "in mice"?
Only if you consider Europeans mice, I guess?
Considering it has the same population as the US, are you also mice?
The EU has approximately 110 million more people than the USA.
guys... I only mean "cool there's a new...oh, not for me" re the fuck lax