Hacker News Reader

Comment by versluis | Hacker News Reader

I love GrapheneOS. The biggest downside is that Google integrity API block wireless payments in Google Pay. All Dutch banks now advertise to install Google pay for wireless payments. I've tried asking Google to support GrapheneOS but they told me to do a feature request. Which I did and got no reply to. I've contacted the consumer market authority and made a formal complaint since Google and Apple share effectively a contactless payments duopoly and decide which OS distributions get access. Those are closed source and usually bundled with a lot of spyware. I also explained how the Google integrity API might affect banking availability in the future (and already does for some banking apps). They took it very seriously and I hope to hear from them in the future.

View on HN

You can use Curve Pay for tap-to-pay on GrapheneOS in most of Europe including in the Netherlands. It also works in the UK, not just the EU. It unfortunately hasn't launched in the US yet.

Some of those banks may also still support using their own tap-to-pay. Europe has a standardized system for it and many banks support it. Check https://privsec.dev/posts/android/banking-applications-compa... for those banks. There was a major shift to using Google Pay to reduce their development costs but there may be a major shift away from it now.

https://grapheneos.org/articles/attestation-compatibility-gu... should be sent to companies banning using GrapheneOS via the Play Integrity API. They can keep doing that while permitting GrapheneOS in a more secure way. Our users recently convinced several banks to implement it. Swissquote implemented it for their Yuh app and will hopefully do it for their main Swissquote app soon. It would be nicer if they didn't add Play Integrity API in the first place but progress can be made if users leave lots of reviews, support requests, etc. until they realize it's a big issue and either remove it or implement this as a replacement.

icard NFC payments also work fine

> All Dutch banks now advertise to install Google pay for wireless payments.

That sounds like a very big mistake to me. And a missed opportunity: in some countries, banked work together to develop their own systems. People can send money to each other and pay everywhere with a small app that is not BigTech from the US.

I think there should be such an app in every country; you don't want your payment system to fully depend on US companies.

Generally what you're describing is in countries that don't have widespread adoption of NFC payments. In Europe almost every country has standardised NFC payments so Apple/Google Pay is the most frictionless option for users.

Switzerland (which is not a country that doesn't know how to do banking :-) ) uses Twint (a Swiss app) with QR codes instead of NFC. To me it's better than NFC (it works with printed QR codes, e.g. on parking payment machines).

I don't know anyone in Switzerland using Apple/Google Pay, which IMO is a national success.

Switzerland is very backwards on retail banking actually. For example money transfers between bank accounts cost money, aren't instant, and can't be done on weekends.

Dutch banks did this, it is called iDeal: https://www.ideal.nl/en/

iDeal is ubiquitous in The Netherlands for individuals sending money to each other, and for online payments. However it does not support NFC payments in physical stores. Dutch banks decided to go with Google/Apple wallet for this. I believe in the longer term Wero https://wero-wallet.eu/ (and potentially the digital euro https://www.ecb.europa.eu/euro/digital_euro/html/index.en.ht...) is supposed to take over this usecase in the EU.

That sounds good! Instead of NFC, they could use QR codes. All the payment terminals can show a QR code, and it's even possible to print a QR code on a piece of paper without the need for the terminal.

Twint does that. They started trying to make it "seamless" with NFC, but couldn't do it because of Apple (maybe now with the DMA it may change) and went for some kind of weird bluetooth stuff. Nobody used it. Then they moved to QR codes, and it quickly got very popular.

Everybody understands QR codes. No need to know whether your phone supports NFC or not, no need to go check if NFC is enabled in the settings, nothing. Everybody understands that they need to scan the QR code with their camera, period. Seems perfect to me.

> they could use QR codes

It already does for web purchases, so there is no reason it could not. Not sure why this is not more commonplace.

Banks do that for p2p payments and e-commerce (like iDeal mentioned by sibling comment or BLIK in Poland).

For physical transactions there's barrier of hardware and network effect - everybody has card terminal. Users expect near 100% acceptance for them to use payment method daily.

If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible, but more expensive and often disliked by the users due to inability to easily switch between cards issued by different apps.

> If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible

Is it? Last time I checked, Apple & Google were also interfacing with banks on the server side, i.e. banks had to integrate with Apple/Google specifically. I'd love to be wrong, though.

I believe that for a long time, Apple was preventing the use of NFC (or was it just for payments?). The EU Digital Markets Act is supposed to prevent them from doing that, as part of the "interoperability" part. And I think the DMA is great in that sense.

True, on iOS access to the NFC chip has been a additional blocker. But on Android apps have been able to use the NFC chip just fine and it's still not that easy to write a generic "wallet" app (that's compatible with all banks & cards), see my previous comment.

>But on Android apps have been able to use the NFC chip just fine

The last time I looked at it, it was not possible because Android doesn't let apps control the uid that gets used for NFC.

Ah right, good point. I did forget about that.

Either way, even if apps had full control over the chip, my understanding is that building a wallet app would still amount to much more than just interfacing with the NFC chip.

You need connection to card scheme, which means you need ton of paperwork, which means you need ton of money. That's biggest issue :-)

For technical side - there are companies selling complete SDKs.

Could you elaborate? You seem like you know quite a bit about this topic.

While I've known that building a wallet is not as simple as configuring the NFC chip and one would have to interface with banks on the backend etc., I've failed to understand exactly why. What prevents a phone from emulating a regular physical credit card?

On technical level - nothing. Thing is, that payment card is basically private key, that's derived from master key controlled by the bank. This key signs your transactions. Tokenization adds some extra steps (eg. single use keys), but it's fundamentally the same.

What it means - you cannot obtain working card profile if bank doesn't issue it to you. Therefore you need blessing from bank & card scheme to be connected to this ecosystem.

If you want to go deeper into this rabbit hole I can recommend two sources:

* https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization

* https://developer.verestro.com/books/token-requestor - actual solution. It focuses on offering for single issuer, because market for Google Pay competition is pretty narrow, but technically it's mostly the same + way more red tape.

If you ever decide to try - ping me, I happen to know a few guys there :-)

Thank you so much! That's very enlightening!

> If you ever decide to try - ping me, I happen to know a few guys there :-)

Ha, I have actually been entertaining that idea for quite some time, but it seems rather difficult to penetrate that domain as an outsider. The links you shared only seem to confirm that. :-\ I'm not sure I would even want to compete with the Google/Apple Pay duopoly, for now I'd mostly just be interested in an open-source, privacy-preserving solution for contactless payments.

Anyway, you might want to add your contact info to your HN profile – just in case. ;-)

>What prevents a phone from emulating a regular physical credit card?

If this were possible fraudsters would be easily be able to clone people's cards by getting close to them. The protocol was explicitly designed for this to not be possible. There are secrets that live on the card itself and are not exposed

So a phone can totally emulate a regular physical credit card, if it has the private key.

Behaving like a credit card does not mean that the credit card is clonable.

Yes, if you want to write an app, that will generate transaction conforming to the protocol & will use your card number it's actually very short programy.

With some luck it will be even routed to your bank. Then it will fail due to invalid authentication. I think there's a defcon talk on YouTube that details the exchange.

Many NFC chip don't allow setting uid either, and none of the EMV card require cloning uid

It's optional if you want "add to wallet button".

That's not related to ability to create own app - on both ios and Android you can access NFC hardware directly (on iOS it's limited geographically), and send card data as you see fit - Google & Apple do nothing in such case.

As mentioned in the sibling comment, Twint goes with QR code. It just works.

It's even better than NFC because a small store can print their QR code on a piece of paper and not need to buy a terminal. Most stores just have the normal card terminal print the QR code and people scan it.

NFC, for payments, has bidirectional communications and limited scope for MITM. It's a bit too easy to cover a sticker.

The TWINT app says -- if their promo videos are to be trusted -- "Scan only QR codes from trusted sources and check the receiver of the payment in the next step". That doesn't fill me with confidence :(.

A dynamic QR code could be fine -- they have their app, you're able to bootstrap what is effectively a secure channel between the PoS machine and the app to give the vendor confidence their device has received payment and the consumer confidence that they're paying the right vendor. A static QR code is more challenging, and it sounds like they're putting more weight into social protections than I'm comfortable with -- especially considering a technical solution is possible and exists.

I'm especially wary of the warning that individuals can't have QR codes. Why not? Unless it's part of the social protection. But I can personally accept NFC contactless payments (having opened an account with a suitable provider), and indeed I bought a device which means I can accept chip and PIN payments too.

Multiple things here.

* The vast majority of the payments (almost all of them) are done with dynamic QR codes.

* The static QR code is mostly used by very, very small entities. Like the person asks you to scan their code, enter the amount and show them the confirmation. It is in their interest to show the right QR code.

* Sending money to a friend is done with the phone number as an id. It works, but you need to enter the mobile phone number of the receiver.

* There is one situation where static codes are printed and where phishing has been reported (it's not MITM, it's really just a QR code that sends you to a bad website): when paying for parking. You don't have to use it if you don't feel comfortable, and it is possible to feel comfortable because it actually just opens a website (so if you use it regularly you can learn to check that you are on the legit website before you make the payment).

Overall, it is super popular and it works really well. No need for NFC, and no need to install the Google Play Services \o/.

I'm sure it does work really well -- the social dynamics are there, it's obviously easy to use. That doesn't mean I have to like the technical characteristics.

A counter-point might be that my credit card doesn't require Google Play Services either. And won't run out of battery. And works with all the local businesses, including the smallest -- while there are some people (mostly outside cities) who still only take cash, I can't imagine them signing up for TWINT either.

There are several providers of services allowing individuals and small traders to accept credit and debit cards, and I've happily accepted cards from foreign banks too.

I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.

> That doesn't mean I have to like the technical characteristics.

I didn't say you have to like them. But if you claim they are insecure, I feel like it's my right to note that you may be wrong.

> A counter-point might be that my credit card doesn't require Google Play Services either.

That is not exactly a counter-point in a discussion between a mobile app doing NFC and a mobile app using QR codes, is it?

> I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.

That's another question. My original point was that non-US banks should not depend on Google Play Services or Apple Pay (which at least until very recently was the only way to pay with NFC on iPhones, wasn't it?).

I agree, but in this banking apps (around me) use the Integrity API anyway.

Thanks for doing that. I tried GrapheneOS a few years ago in the states, and the bank thing wasn’t a huge problem (just carry rfid cards because there’s no google pay/apple pay).

The bigger problem came from apps that threw null point exceptions on startup when probing for google play crap.

The following failed for at least one week over a two month period: parkmobile, multiple ev charging networks, uber, lyft, yelp.

Is this still an issue, or are things more reliable these days? (Ignoring the Google integrity stuff.)

I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox. Then it dropped to advertised. You might want to add that to your complaint. Halving everyone’s battery life is easily quantified economic damage. (Privacy is more important than bundling $50 of battery, then wasting it, but easier for Google to wave away with big words and doublespeak.)

The app crashes I found were always due to the additional security hardening features in GrapheneOS. You can toggle these individually for each app.

> The bigger problem came from apps that threw null point exceptions on startup when probing for google play crap. > > The following failed for at least one week over a two month period: parkmobile, multiple ev charging networks, uber, lyft, yelp. > > Is this still an issue, or are things more reliable these days? (Ignoring the Google integrity stuff.)

These apps have worked reliability since our sandboxed Google Play compatibility layer added support for them in 2021. There wasn't a time period where these apps weren't compatible with GrapheneOS after they initially became supported. That was a problem with your setup, but there's no way to figure out what was wrong at this point. Updating sandboxed Google Play without keeping the OS updated is not supported. If you fell significantly behind on updates but were still getting sandboxed Google Play updates, that would explain why things broke. We sometimes gate those updates. We do keep things working for legacy extended support devices, but whether people are on a fully supported device or a legacy one they're expected to keep the OS updated. We don't keep compatibility with old OS versions indefinitely. Disabling the Network permission for sandboxed Google Play services or sandboxed Google Play Store is another possible cause. Regardless of the cause, that's not at all normal and doesn't reflect a typical experience.

> I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox.

GrapheneOS will still tend to get better battery life with the same apps installed by the user unless you install a bunch of other Google apps to match the stock Pixel OS out-of-the-box experience. It's easy to make battery life worse by having multiple push messaging systems running at the same time though. Installing sandboxed Google Play in 2 separate profiles you always keep active could easily have worse battery life than the stock Pixel OS since it's 2 whole separate isolated instances of it vs. the stock Pixel OS having them built into the OS as highly privileged cross-profile system services.

Thank you for doing that. Integrity API is fucking evil, and Google has somehow managed to sell it as a security measure even though it is all about taking control away from people and concentrating it at Google.

I just use contactless cards now. I’m done with tying my financial capability to a third party device. If I want to pay someone directly it’s PayPal family and friends or direct bank transfer.

Yea, I really don't understand how using a phone is any simpler than just tapping my debit card at the terminal. There's no way in hell I'm letting Google anywhere near my personal finances.

Nfc card payments have a pretty low max limit at least without a pin.

Phone nfc payments do not.

Using a phone is simpler if all you have on you is your phone, which was my use case when my bank hadn't offloaded their wallet app to gpay. That, and having the phone already in hand for customer/loyalty cards.

So yes, it's handy. Jot handy enough to use gpay for it, of course, but handy nonetheless.

Did you do your complaint at ACM? I want to follow your example

I did using their website form. It needs to be clear from the complaint that Google is violating fair market principles. They also like details about what exactly is happening and who is affected. That was why they called me after I filed the complaint.

I would love to chip in and see if we can get this ball rolling, usually I feel like I'm the only person who cares or files AP/ACM/... complaints and then it's too small beans for them to care. I'd not submit the literal same thing again, but could you share what wording you've used? Specifically in this case I'd also not be sure whether this blocking of Graphene etc. is abuse of market power when there is another option on the market (Apple) and so it's not a monopoly

There's no contact info in your profile so I couldn't reach you. If you don't want to share it here, you could use the email address in my profile

Good that you mention it. I will add contact details. It has been a while so I don't remember the exact wording. I wouldn't use the same wording since it is not a petition and doesn't add value. They want to research if it is an unfair practice. In my opinion banking and wireless payments is a common good. Having two companies, who only approve software of partners, most of them including unremovable spyware, is limiting on access to banking and privacy (although privacy is another department). I mentioned security since that is Google's argument for the block even though GrapheneOS is more secure than approved builds. I gave the number of GrapheneOS users to make clear it doesn't affect only a few individuals. I think LineageOS users might also be affected?

It shouldn't work like a petition, but these organisations do treat it as such unless something is very obviously a major violation. Even with numbers of Graphene users, what part of that is Dutch? What part of that wants to use Google Pay? What part makes use of a workaround? Multiple reports of problems does give some information/signal that this is worth their time

But yes, as said I'd not use the same wording because it shouldn't just be a copy-paste, that's also wasting their time. I could refer to what was already submitted so they can more easily bundle them, but I understand you don't have it anymore so np. Thanks for mentioning you've submitted this in the first place and the additional info, that does motivate me to continue also submitting things and to know better what makes sense to submit :)

It’s great. Thanks for doing that. The French concurrence authority would probably love that type of reasoning. Specially now that the US is officially an adversarial entity.

Reply on news.ycombinator.com