One of ours biggest customers is mainly used by Ukrainian refugees as easy way to pay abroad. USDC/USDT is simply cheaper and more available to them than regular USD.
* App is allowed to decide if I can (manually) take screenshot/ocr the screen - usually it's banking app, that wants me to remember some long number - then I write it on closest piece of paper - awesome security. No workaround as far as I know.
> App is allowed to decide if I can (manually) take screenshot/ocr the screen - usually it's banking app, that wants me to remember some long number - then I write it on closest piece of paper - awesome security. No workaround as far as I know.
The workflow that I've seen was someone I've known for under a month asking me to photograph her screen and send the photograph over Telegram. Surely that is more secure than letting her just screenshot her own device.
I'm not liberal Anglo(or any Anglo), so let me explain - Russia attacked Ukraine, because it thinks it's imperium. Russia kills Ukrainians and destroys their country for their sick ambitions.
Fact that other countries use the war for their own politics doesn't change it in the slightest.
Take a look at Home Assistant - I would argue their implementation is currently better than both Siri & Gemini assistants.
HA team is releasing actually useful updates every month - eg ability for assistant to proactively ask you something.
In my opinion both Google & Apple have huge issues with cooperation between product teams, while cooperation with external companies is next to impossible.
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.
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.
* 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?).
> 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.
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.
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.
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.
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.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 :-)
> 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
Aren't there several protocols? I understand NFC chips or the old-school "phone card" UICCs are probably quite difficult to clone but at least in the US swiping credit cards (+ physically signing the printout maybe) still seems to be quite common.
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.
No hardware on the phone to emulate swipe :-) But yes, magstripe is easy to clone - main reason why it is dying.
The one you shared is fine, but it's overview on whole ecosystem. Something NFC focused would be probably more helpful like these two https://youtu.be/7ElZBI9PufY
IMO advertising itself is ok, if not targeted by profiling user. I'm reading about bikes and I'm offered a bike or helmet? Fine by me.
Problem starts, when I'm scrolling $socialWebsite and I see ton of biking ads, because some Orwellian ad network is tracking me through time & space.
Then content starts to serve as means to push ads into my eyes whenever I dare to open them. If content is crap - doesn't matter - if I switch to other source ad will follow.
What's worse - many people were brainwashed into believing that's normal. I remember guy from Chrome team, who published draft for web attestation. He was convinced he's doing good thing because brands have "right" to be sure they're getting real eyeballs and he was just making this process "better" for the users.
It's not. It enables free content, but most of it is crap quality.
Assume there's no ad network that tells you that user is into high-end bikes. You cannot produce cheap rage bait and then market bikes, because you'll likely miss your target audience. You have to produce good biking content and then advertise bikes to be effective.
This is basically "break for our sponsor" you see on YouTube - for me personally youtube sponsorships are way more bearable than typical ad infested "news" site
reply