Activity
aerique commented
on Aug 29, 2022 Tried with one of my customers but you cannot log in to the app without Google Play Services @aerique Please correct this @akc3n
No, do not correct anything yet. Lets first figure out which app we're talking about.
I'm using the top app which is the generic banking app. It's updated, I can login, I can scan QR codes and pay. I use it almost every day, sometimes multiple times. I also do not have Google apps installed, not even in GrapheneOS' sandbox.
I've also used this app (until a few weeks ago) on SailfishOS on its Android emulation which also does not have Google Play Services.
I can also confirm that the second app "mobiel betalen" does not work for me. This app is for wireless payments.
changed the title
[-]ASN Bank App From the Netherlands[/-][+]ASN Bank App - Netherlands[/+]on Oct 26, 2022 joepie91 commented
on Nov 5, 2026 Quoting from that EPI/Wero response above:
Wero was launched with the goal of making the service available to as many consumers as possible across our core markets. To achieve this, we currently focus on supporting the most widely used mobile banking platforms and devices.
That is really not an acceptable response for critical payments infrastructure that is required to participate in society (particularly in places where it is about to fully replace the previously existing infrastructure), and I think it is a very good reason to start swinging around threats of contacting financial regulators about it (whose approval the whole system lives and dies by).
Reacted by Tako, Wouter, borv3, Nick B., Thomas Makryniotis, idadiv, Jeroen Versteeg, Maximilian Blacher, CPTN_Cosmo, Lars Maxfield and 8 more
danieldk commented
on Nov 6, 2026 That is really not an acceptable response for critical payments infrastructure that is required to participate in society (particularly in places where it is about to fully replace the previously existing infrastructure), and I think it is a very good reason to start swinging around threats of contacting financial regulators about it (whose approval the whole system lives and dies by).
I not extremely familiar with all the legal details, but as far as I understand, this will also violate PSD3, since a bank cannot force customers into a single authenticator.
I think it's also good to emphasize to ASN in private communication and publicly that they sell themselves as a idealist/green/a better future, which is a stark dichotomy to throwing non-big tech users under the bus.
Reacted by CPTN_Cosmo, Lars Maxfield, Richard van Laak and mielas
Tasqa commented
on Nov 6, 2026 I got the following response from my official complaint. Unfortunately there is no way to respond without escalating further 👎
Uw klacht
Onze reactie
Als bank maken we voor onze dienstverlening regelmatig gebruik van externe leveranciers. Waar mogelijk beoordelen we de risico's op het gebied van privacy, informatiebeveiliging en continuïteit, en proberen we deze te beperken tot een acceptabel niveau. Zijn de risico's onacceptabel, dan maken we geen gebruik van de leverancier.
Voor gezamenlijke betaalinitiatieven, zoals iDEAL | Wero, volgen we de kaders en veiligheidseisen die partijen gezamenlijk vaststellen.
De mogelijkheden voor de toekomst
Conclusie
Reacted by idadiv and Wesley Schaft
ranjowd commented
on Nov 6, 2026 Uw klacht
Onze reactie
Voor online betalingsverkeer via het nieuwe iDEAL | Wero geldt strenge Europese wet- en regel strenge regels rondom privacy, veiligheid en het voorkomen van fraude. iDEAL | Wero stelt daarom hoge eisen aan de beveiliging en integriteit van apparaten die gebruik maken van de betaalmethode.
iDEAL | Wero maakt gebruik van de standaard beveiligingscontroles voor reguliere besturingssystemen. Doordat alternatieve systemen deze ingebouwde beveiligingen overslaan of vervangen, garandeert iDEAL | Wero de veiligheid van de transactie niet.
Als bank maken we voor onze dienstverlening regelmatig gebruik van externe leveranciers. Waar mogelijk beoordelen we de risico's op het gebied van privacy, informatiebeveiliging en continuïteit, en proberen we deze te beperken tot een acceptabel niveau. Zijn de risico's onacceptabel, dan maken we geen gebruik van de leverancier.
Voor gezamenlijke betaalinitiatieven, zoals iDEAL | Wero, volgen we de kaders en veiligheidseisen die partijen gezamenlijk vaststellen.
De mogelijkheden voor de toekomst
Conclusie
Reacted by Wouter, Nick B., nyo, Frank Oosterhuis, mielas, Daniel and Daniël de Kok
lucasvbeek commented
on Nov 6, 2026 Part of a new reply by EPI:
Second, on why Google Play Integrity is required rather than Android hardware key attestation alone: Android hardware key attestation verifies that a cryptographic key pair was generated inside a hardware-isolated environment, such as a TEE or StrongBox, and that the key has not left that boundary. What it does not verify is the integrity of the calling application and the runtime operating system.
In payment systems, compromised or tampered execution environments present a major attack vector. EPI Central Services and our underlying payment tokenisation components require assurance on several layers before issuing tokens with payment authority: that the application binary has not been tampered with or repackaged, that the app is distributed through an authentic channel, and that the operating system has not been modified or hooked by debugging or emulation tools. Google Play Integrity provides these combined signals in a signed token that our backend verifies server-to-server. Hardware key attestation is an important building block, but on its own it does not give the full application and OS integrity verification that our risk and fraud models require.
Sidenote: apparently Wero does not require payments to be made through a mobile app. There's a separate web-to-web flow (similar to current iDeal payments that are completed on laptops/desktops), but ASN chose not to implement this.
I'm planning to respond with some follow-up questions about the exact required Play Integrity level since Wero does work with other banks. As far as I know their explanation of the Android hardware attestation is also not entirely correct, but I have to look into that further first.
orazioedoardo commented
on Nov 6, 2026 What it does not verify is the integrity of the calling application and the runtime operating system.
That's blatantly false and it's atrocious that a EUROPEAN payment system depends on an AMERICAN service that the US could shut down in minutes.
that the app is distributed through an authentic channel
This has zero security value. If the app is authentic, you might as well have downloaded it from a cybercriminal server.
Reacted by aleksandarResolume, Davids Paskevics, StealWonders, Robert Lag, Matthijs Hakfoort Codecraft, idadiv, daw1lli, Wouter, Prasoon Shukla, nicman23 and 3 more
readefries commented
on Nov 6, 2026 Uhm, isn't this supposed to be software that enables EU tech sovereignty, not work actively at achieving US vendor lock-in?
I would certainly hope so! Odd thing is, in the interview with the WERO CEO in RTL. (Sorry Dutch):
Soeverein zijn als Europa
Op geopolitiek gebied moet Wero ook een factor worden als het aan Weimert ligt. Ze doelt onder meer op de afhankelijkheid van grote Amerikaanse betaalbedrijven Visa en Mastercard. Het continent is volgens haar kwetsbaar als het betalingsverkeer met bijbehorende data vooral verloopt via partijen van buiten Europa.
Reacted by Nick B. and Frank Oosterhuis
danieldk commented
on Nov 6, 2026 Part of a new reply by EPI:
Second, on why Google Play Integrity is required rather than Android hardware key attestation alone: Android hardware key attestation verifies that a cryptographic key pair was generated inside a hardware-isolated environment, such as a TEE or StrongBox, and that the key has not left that boundary. What it does not verify is the integrity of the calling application and the runtime operating system.
Since you seem to have a working line of communication with them, please point out that this is wrong:
The standard hardware attestation API can be used to verify the authenticity/integrity of the hardware, firmware, OS and the app running on it. It provides a verified boot key fingerprint for the OS for permitting secure aftermarket operating systems. The app ID, signing key fingerprint(s) and version code of the app enabling hardware attestation are included in the signed public key certificate for the generated key. This enables the app's service to make sure the app is genuine and unmodified along with chaining trust through the OS to the app which can sign messages with the attested hardware keystore key to prove they come from their app running on top of a verified OS, firmware and hardware.
https://grapheneos.org/articles/attestation-compatibility-guide
