4 ms·
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 mos
by jrmann100 4y ago
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://chrome.google.com/webstore/detail/google-tone/nnckehldicaciogcbchegobnafnjkcne https://chrome.google.com/webstore/detail/google-tone/nnckeh...
- spike021 4y agoIIRC, Webex Teams used to do something like this if you walked into a conference room that had a Webex teleconference setup. I haven't used it in a few years, though.
- mrud 4y agoSame thing with zoom rooms - https://support.zoom.us/hc/en-us/articles/214629303-Direct-sharing-in-Zoom-Rooms https://support.zoom.us/hc/en-us/articles/214629303-Direct-s...
- akelly 4y agoGoogle also used ultrasonic pairing/auth for Chromecast https://www.theverge.com/2014/6/26/5846726/chromecast-will-use-ultrasonic-sounds-to-connect-nearby-devices https://www.theverge.com/2014/6/26/5846726/chromecast-will-u...
- jjeaff 4y agoI 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 strangely named device among the dozen or so devices that inevitably show up, ultrasound would be a great way to transmit the initial credentials.
- hgomersall 4y agoThe key exchange problem doesn't go away because you're using ultrasound.
- kevin_nisbet 4y agoCorrect, 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 boots with an unsecured wireless network. And an app on the phone is used to connect to the network, and share the wifi password, and then rendezvous on the wifi network to continue provisioning. I think there are some protocols for this that I don't fully remember now. There's lots to consider in this method, such as can someone sniff the transfer, how is that protected, what is the range to pick up, etc. Can someone trick the app into connecting to some other device, etc, etc. If you put mitigations in, how can those be countered. With sound / ultrasound based provisioning (the device I'm talking about already had a microphone and speaker), the range is more limited to who can hear the device. The signal strength is much weaker, an eavesdropper might need to be in the same room. This might allow weaknesses in the overall model of key exchange to be less of a concern, as the properties change to something a lot harder to intercept.
- hgomersall 4y agoIt 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.
- baybal2 4y ago
- kevin_nisbet 4y ago
- mlambie 4y ago
- Cthulhu_ 4y ago> 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 update or setting change away.
- danuker 4y ago> 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.
- infinityio 4y agoTo 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
- quesera 4y agoThis 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.
- samatman 4y agoAnthropomorphic 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.