161–170 of 194 posts
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 acc…
> 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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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/…
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.
Earlier quoted context omitted.
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.
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).
Earlier quoted context omitted.
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 acc…
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.
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.
Earlier quoted context omitted.
"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...
like wtf is this answer, its like y'all give up from starting point
Earlier quoted context omitted.
> 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,…
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.
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.