Hello,
I saw some tweets that GrapheneOS will try to figure out a solution for NFC Payments after they release support for Android Auto.
I still didn´t setup Google Wallet even for my tickets/QR codes because it will prompt: “Google may use the information to generate entries in your Google Calendar” which I don´t want…
So I am curious if NFC payement support in GrapheneOS will generate a change in the community approach to Google wallet?
On the other hand, is there an App that can handle website generated links for “add to Google/Apple wallet”?
Thank you!
Jonah did a video on how google and apple pay work and essentially, Apple Pay is kinda more private because it functions locally on-device and offline, whereas Google Pay needs connections to the Google servers at least periodically due to how tokens for payment are generated.
So basically, even if I had the option to use gpay on graphene I wouldn’t.
@anon28734771 : Thank you. My understanding the solution is using hardware attestation instead of Google´s for NFC, which needs App support implementation anyway (hopefully as they move to more secure implmenetation).
@pinkandwhite : I saw the video thank you. I am not moving back to Apple after escaping their eco system, but you are right. As I mentioned in my first message, I am not even comfortable putting an entrance ticket in Google Wallet yet (they will automatically scan it and create a Calendar entry for the event).
And yes, I have the same question as there is no reference anymore to Android Pay.
I wasn’t suggesting moving to Apple, I was just summarising the video as that explains my reasoning for not using Google Pay even if Graphene were to make it functional.
@pinkandwhite Undertstood, thank you again for the video! @anon85295620 Cash I understand (it is king). For the credit cards, I think that is debatable. They are neither secure nor private.
If it would work like Apple Pay, where the card is basically just inside the secure element of the phone, then yes I would use something like that. If it works like Google Pay, no. They generate your payment tokens on some cloud servers.
@anon28734771 is referring to AOSP’s host-based card emulation API, which allows banks (or any app) to implement NFC payment support directly in their own apps, not the old (circa 2015) “Android Pay” app which became Google Wallet and/or Google Pay.
I don’t know of any American banks which implement this feature on Android personally, but I understand it is commonly used in the EU. When that feature is used, it should directly interface with your banking provider without any (Google) middlemen.
I’m not sure why this functionality wouldn’t work already on GrapheneOS though, so it does seem a bit unrelated to this thread (but I haven’t tested it).
I absolutely love that Wikipedia had to create a flow chart to decipher Google’s ridiculous naming schemes:
Indeed this is also unclear to me. Sadly even here in the EU the banks supporting this are becoming less and less and instead use Google Pay. Would be interesting if at some point there could be a company that is mostly privacy-focused act as a bank. Depends mostly on consumer demand.
From some research online, [1][2] it appears not. The most comprehensive answer about this is at the partner thread to this: [3]
My understanding is that AOSP has a host-based card emulation API which can only be used by an application, such as a mobile banking app? If that’s the case, that isn’t really an alternative to Apple Wallet or Google Wallet as it requires you to have a dedicated app. While it’s common for most banks to have mobile apps (which are all but guaranteed to be proprietary, not open source) there are still some financial institutions which might not. More importantly, there are many features that would be lacking in comparison to Apple/Google Wallet such as:
There are some apps which try to do some of these things, but they seem very limited in scope and functionality. For example, you apparently cannot make payments with Catima which to me is the main point of having a mobile wallet in the first place.
However, per my response to it, all the necessary parts of the stack appear to, nowadays, be FOSS and accessible from unprivileged userspace. [4]
