Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A big win for Android interoperability

openhomefoundation.org

Post reply on HN
Print view View original

111–120 of 194 posts

Re: A big win for Android interoperability

#111

Post by kelvinjps10 »

jorvi wrote: post #87
shiandow wrote: post #22

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.

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 h…

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

Re: A big win for Android interoperability

#112

Post by nextos »

wltr wrote: post #47
tjoff wrote: post #42

Earlier quoted context omitted.

Because a normal card is superior in most practical cases?

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.

You need them in some scenarios. For example, lots of car rental companies refuse to take anything but a physical card.

Re: A big win for Android interoperability

#113

Post by microtonal »

inigyou wrote: post #85
stavros wrote: post #83

Earlier quoted context omitted.

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.

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.

Re: A big win for Android interoperability

#114

Post by inigyou »

miroljub wrote: post #92
inigyou wrote: post #64

Earlier quoted context omitted.

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.

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.

Re: A big win for Android interoperability

#115

Post by inigyou »

microtonal wrote: post #113
inigyou wrote: post #85

Earlier quoted context omitted.

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.

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 requiri…

POSIWID: the purpose of remote attestation is to force people to buy devices that pay Google license fees.

Re: A big win for Android interoperability

#116

Post by carlosjobim »

m12k wrote: post #52
inigyou wrote: post #45

Earlier quoted context omitted.

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.

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.

Re: A big win for Android interoperability

#117

Post by svpk »

giantg2 wrote: post #103
microtonal wrote: post #68

Earlier quoted context omitted.

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 gove…

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.

> 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.

Re: A big win for Android interoperability

#118

Post by carlosjobim »

wltr wrote: post #49
inigyou wrote: post #46

Earlier quoted context omitted.

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.

Your bank will refund any stolen money if your card is stolen.

Re: A big win for Android interoperability

#119

Post by throwaway87543 »

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.

Re: A big win for Android interoperability

#120

Post by hollow-moe »

jeroenhd wrote: post #106
hollow-moe wrote: post #18

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 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 t…

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...
Post reply on HN