Hacker News new | ask | show | jobs
by olliej 1590 days ago
What is the other way of doing it?

Because this “hack”:

* Works on devices without Bluetooth (or that have it disabled)

* doesn’t require anyone installing privileged software or drivers

* gives a very good “in the same room” indicator

* doesn’t require any custom/expensive hardware components

3 comments

The mechanism is not the problem, it's that it turns on the mic by default. Most Zoom users are not in the luxury position of being in a location with a presentation room where they might need to present something, so for most people this is just an unnecessary feature and a possible nuisance. So this setting should by default be turned off (it can still work when the mic is turned on already).
I was responding to the comment calling it a hack :)

Zoom deciding to use the mic while not in use is clearly a terrible bit of behavior :)

If I have NFC or Bluetooth disabled it is because I explicitly do not want software on my device to contact outside services.
Yes, but if you’re in a zoom/whatever conference room, with a zoom/whatever client running, it’s not unreasonable to think that you want to use the conference equipment. Couple with the various constraints on BT, etc this is a reasonable solution.

Where this reasonable solution is actually implemented securely is another question, and Zoom’s track record isn’t exactly fantastic.

But how is the device going to communicate with the zoom hardware in the room when Bluetooth is disabled?
The ultrasound is the communication.

From the description it sounds like it's just a handoff feature, as in you go into a conference room with whatever their conference room product is.

Once you get in handoff range they only need to exchange sufficient information to get the AV equipment to start a connection to the appropriate zoom/webex/whatever channel, and presumably the reverse of getting the original zoom client to close.

I'm assuming there is some work to reduce the likelihood of unintentionally triggering it, and some basic authentication, but this is not a lot of data, and ultrasound is more than sufficient to do it very "instantaneously".

OK, so the actual communication (the call itself) will be transmitted over wifi. But this means that at least some kind of access token must be transmitted over ultrasound. Is this safe? I would love to see an analysis of that communication; whether it is encrypted, is the handshake secure or can it be hijacked, does,it transmit only an anonymous access token or the whole user ID etc.

I mean, if I ever switch off Bluetooth it's exactly for the reason that I don't want my device to be detected/tracked. Zoom going around this by using ultrasound is kind of mean, since I can't prevent zoom from using audio if I want to be able to make calls.

> OK, so the actual communication (the call itself) will be transmitted over wifi

That was my interpretation of the feature described earlier in the thread

> But this means that at least some kind of access token must be transmitted over ultrasound. ...

Yup, I agree I'd love to know more about what is involved. I like to think there's a degree of authentication involved, but this is also Zoom. The company that installed a persistent service in order to circumvent a security feature in safari, that also allowed unauthenticated RCE.

> I mean, if I ever switch off Bluetooth it's exactly for the reason that I don't want my device to be detected/tracked.

I had assumed Android and PC had adopted the randomized MACs apple uses to prevent such tracking?

> Zoom going around this by using ultrasound is kind of mean, since I can't prevent zoom from using audio if I want to be able to make calls.

If we assume for now that it is properly authenticated, and has safe tokens to break tracking, identification, etc, then this behaviour seems reasonable. It would require you to open zoom in a room with the requisite enterprise-y teleconference equipment.

But of course that is quite a load bearing "if", and it already appears that they're trying to maintain the channel when they aren't active.

> I had assumed Android and PC had adopted the randomized MACs apple uses to prevent such tracking?

True, and this is why I rarely switch it off, except in situations where I don't want to be visible to devices that I previously connected to. Same for wifi.

I just find it quite over the top to work around user-controlled communication channels like bluetooth that the user might have chosen to disable, by using a medium (sound) that the user cannot switch off and still use the app.

In this case it's a convenience feature, rather than a avoid user controlled channels thing.

As I noted earlier it works without bluetooth available, but more importantly I suspect, if it were bluetooth everyone would have to peer their devices with every conference room. If it were wifi you'd need to know the network name of the conference room's AV system.

While both options would work, having a single "switch to AV system" button is clearly the best user experience, so you try to make that possible. Given both the app and the AV system have the ability to create and record sound, that's the obvious choice.

But again, I'm not making any statement on the security of the actual implementation from Zoom :D