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

Ultrasonic Payments

charliegerard.dev

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Ultrasonic Payments

#71

Post by infinityio »

danuker wrote: post #66
Cthulhu_ wrote: post #59

Earlier quoted context omitted.

> Tone also came with the unfortunate side effect of Google software having constant access to your microphone. In today's world, most phones or "smart" devices are also constantly listening; I want to believe they don't listen until the trigger phrase is uttered, which could also be implemented for these ultrasonic applications, but I'm not entirely convinced and them always listening is but a silent over-the-air up…

> I want to believe they don't listen until the trigger phrase is uttered They can't know whether the phrase was uttered unless they constantly listen.

To be fair, the initial phrase recognition probably wouldn't require 'listening' as such - the trigger phrase could be a very simple program that doesn't have the capability to do anything other than recognise a keyword, and then it bootstraps a program that actually listens to you when it detects it

Re: Ultrasonic Payments

#72

Post by quesera »

infinityio wrote: post #71
danuker wrote: post #66

Earlier quoted context omitted.

> I want to believe they don't listen until the trigger phrase is uttered They can't know whether the phrase was uttered unless they constantly listen.

To be fair, the initial phrase recognition probably wouldn't require 'listening' as such - the trigger phrase could be a very simple program that doesn't have the capability to do anything other than recognise a keyword, and then it bootstraps a program that actually listens to you when it detects it

This is exactly how it works.

The microphone is active and "listening" all the time.

The firmware that detects the wake word compares the constant input stream against waveforms that are designated "wake words". Firmware can be sometimes updated for custom or trained words, but it doesn't hold a large dictionary.

If a reasonable match is found, it kicks the full recording/recognition/streaming code, squirts any buffered audio at it (to catch words that come directly after the wake word and before the full handler is ready), and then things proceed according to plan. Depending on the device and service, recognition might happen locally or in the cloud.

Re: Ultrasonic Payments

#73

Post by alonsonic »

__alexs wrote: post #60
m-s wrote: post #53

Earlier quoted context omitted.

How would you “steal” money from a contactless card or a phone?

1) Gain access to something like a Stripe Terminal ( https://stripe.com/gb/terminal ) You should probably avoid using your real identity here. 2) Type in a charge like $50 3) Discretely wave the device at your targets wallet 4) Repeat steps 2-3 as much as possible in a short amount of time. 5) Hope you can withdraw the funds before anyone notices. I don't think this is a wildly plausible attack and also at least here…

> 1) Gain access to something like a Stripe Terminal (https://stripe.com/gb/terminal)

Getting a payments terminal is not easy, this would requires ID verification and working business bank account (acquirer), this terminals are highly regulated. Someone doing this can get caught easily by just a couple of customers reporting the fraudulent transactions. This is very small risk and is rarely seen.

Re: Ultrasonic Payments

#74

Post by underdeserver »

kybernetikos wrote: post #67
__alexs wrote: post #60

Earlier quoted context omitted.

1) Gain access to something like a Stripe Terminal ( https://stripe.com/gb/terminal ) You should probably avoid using your real identity here. 2) Type in a charge like $50 3) Discretely wave the device at your targets wallet 4) Repeat steps 2-3 as much as possible in a short amount of time. 5) Hope you can withdraw the funds before anyone notices. I don't think this is a wildly plausible attack and also at least here…

This attack (and some variants of it, e.g. fooling the proximity detection or man in the middle) work because the acknowledgement action that the user does is simply having the device nearby. This seems like a poor choice of acknowledgement action for something that transfers money. Payment devices should probably have a physical or soft button that you have to press to acknowledge payment.

Strong disagree. The usability hit is not worth the added security. Having a cutoff for PIN entry requirement and the card issuer taking responsibility for fraud means customers are quite safe (as long as they look at their charges).

Re: Ultrasonic Payments

#75

Post by Aachen »

dancsi wrote: post #43

This reminds me of how the student meal subsidies are implemented in Slovenia, and in my opinion it was quite unwieldy. You call a phone number and place your phone's earpiece on another device with a microphone. Then, some personal data is transmitted using (ultra?)sound. I remember it being quite unreliable, but that might be down to using the telephone network as the data carrier.

> using (ultra?)sound

Phone lines have (or at least had) narrow frequency ranges. I'm not an expert but I'd assume this is just normal sound like any old modem.

Re: Ultrasonic Payments

#76

Post by samatman »

danuker wrote: post #66
Cthulhu_ wrote: post #59

Earlier quoted context omitted.

> Tone also came with the unfortunate side effect of Google software having constant access to your microphone. In today's world, most phones or "smart" devices are also constantly listening; I want to believe they don't listen until the trigger phrase is uttered, which could also be implemented for these ultrasonic applications, but I'm not entirely convinced and them always listening is but a silent over-the-air up…

> I want to believe they don't listen until the trigger phrase is uttered They can't know whether the phrase was uttered unless they constantly listen.

Anthropomorphic language is unhelpful here, filling a ring buffer and running transforms on it looking for a certain shape is one kind of 'constantly listening', and recording a faithful audio stream which is sent to the cloud is another kind, they do the former.

Re: Ultrasonic Payments

#77

Post by samhw »

underdeserver wrote: post #74
kybernetikos wrote: post #67

Earlier quoted context omitted.

This attack (and some variants of it, e.g. fooling the proximity detection or man in the middle) work because the acknowledgement action that the user does is simply having the device nearby. This seems like a poor choice of acknowledgement action for something that transfers money. Payment devices should probably have a physical or soft button that you have to press to acknowledge payment.

Strong disagree. The usability hit is not worth the added security. Having a cutoff for PIN entry requirement and the card issuer taking responsibility for fraud means customers are quite safe (as long as they look at their charges).

You could do something like "you need to be physically holding the card with your hand", which would complete some circuit. I can't think of many cases where that wouldn't work, except perhaps people who don't take their cards out of their wallets(?).

Re: Ultrasonic Payments

#78

Post by moffkalast »

dancsi wrote: post #43

This reminds me of how the student meal subsidies are implemented in Slovenia, and in my opinion it was quite unwieldy. You call a phone number and place your phone's earpiece on another device with a microphone. Then, some personal data is transmitted using (ultra?)sound. I remember it being quite unreliable, but that might be down to using the telephone network as the data carrier.

> (ultra?)sound

Well it's not ultra I'd say, that screeching is quite audible. Very similar in sound to an old phone modem.

I think the system it uses is the same as for Moneta, which can be used in much the same way but gets billed to the sim account instead. I'm sure other countries also use the same principle for some services.

Re: Ultrasonic Payments

#79

Post by baybal2 »

hgomersall wrote: post #63
kevin_nisbet wrote: post #41

Earlier quoted context omitted.

Correct, although it's not that it goes away, more of a it has different properties. The short time I worked in the IOT space, I was a big proponent of exploring an option like this for bootstrapping the WIFI connection in a device that otherwise had just a button or two. The basic problem is, the wifi password needs to be shared with a device without an interface. The traditional method at the time was the device bo…

It feels to be that this is better solved with NFC. The hardware is in principle cheaper with NFC (certainly, cheaper transducers) and my understanding is nfc is more robust to snoopers - certainly ultrasound is explicitly broadcast.

No post body was provided.

Re: Ultrasonic Payments

#80

Post by Auracle »

jjeaff wrote: post #25
jrmann100 wrote: post #17

I'm reminded of Google Tone[0], which beamed URLs audibly to nearby browsers in an Airdrop-style experience. A neat trick, but ultimately useless given that most devices have less obtrusive ways of sharing data P2P. The ultrasonic aspect of this experiment makes the technology a lot more useful. Tone also came with the unfortunate side effect of Google software having constant access to your microphone. 0: https://ch…

I disagree that there are better ways to transmit data p2p in most devices. Even the smoothest of setups for things like iot devices usually require a Bluetooth connection with a passcode or a connection to a lone wifi signal after which you need to switch back. Using sound would be a perfect way to setup iot speakers or really anything close by. Instead of having to activate Bluetooth pairing and find the sometimes…

I’m kind of bummed nobody has copied how they transfer files on The Expanse. For those that haven’t watched, if someone is standing across from you, you simply swipe it to them.

I feel like Apple’s ‘Find my’ tech could work to get positional data and make it possible. You’d need whitelists and the like of course.

Post reply on HN