Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I worked in videoconferencing for a while. When it comes to meeting identifiers, striking the right balance between ease of use and security is really hard.

On the one side, maximum ease-of-use is a name or code short enough for someone to say over the phone. "Here, just jump into the videoconferencing meeting 'mikefred' or 'john10' or '39584'". That works particularly well for small meetings where it's immediate obvious if someone else joins and you can stop talking and ask them who they are and kick them out if they shouldn't be there.

On the other hand is long random identifiers in a space large enough they're impossible to guess. If you're joining a meeting from a link then nobody cares, but if you're telling someone over the phone or typing it into the phone it sucks. (And you are very often needing to jump from one form of communication to videoconferencing, where there's no way to "just paste a link" into the initial form.)

There's also no real difference between a short meeting name plus password and a long meeting name, except that passwords tend not to be displayed on screen so it's even harder to find it to tell someone over the phone.

Also there's another big issue in how easy or convenient you make it for people from within your domain/company to join, versus outsiders. Half the company wants to make it harder for outsiders to join (for security), the other half (salespeople) want it to be easier.

The only solution, unfortunately, is educating users to understand the differences. Zoom already has most if not all the necessary options, even modes like "waiting room". But the same options will never work for every meeting. Whoever hosts a meeting needs to understand the options. There's just no substitute.



This is a really good point, and I actually sympathize with how difficult it is for Zoom to strike the right balance here.

If the only method of operation here were for people to invite others by copy/pasting a URL, and the invitees' only method of joining were to click on that link, then long UUIDs or such would be just fine.

But Zoom lets you dial in audio-only from a regular phone. You simply just cannot use "long random string" as an identifier if you're expecting someone to punch it into a telephone keypad. Even having an 9- to 11-digit meeting code plus say a 6-digit passcode would be a burden for some people, though it's really the only way to do that portion of it right.

Now, one thing I do not cut Zoom any slack for is having an API where you can request validity and status of any meeting ID, without any rate limits placed on it. That's Security 101 right there.


I don't know if botnets are still a thing, but it used to be that any rate-limits needed to be multiplied by 10k for even a modest attacker, as being able to query from 10k unique nodes was a fairly trivial problem by renting a botnet.


Meet has a 10-letters ID for meetings over HTTP and a 9-numbers ID (like zoom) for phoning in. It sounds complicated but in practice every Meet invitation has a single-tap phone link that dials the correct number and input the conference ID after a pause, all encoded in the link. It works flawlessly and so it doesn’t matter if that number is different from the concernce URL you click on a computer.


You are assuming a cell phone that calls in. But lots of people dial in manually from an actual telephone.


Do you have any statistics on "actual phone" usage? I'd imagine it's very low these days.


> Even having an 9- to 11-digit meeting code plus say a 6-digit passcode would be a burden for some people, though it's really the only way to do that portion of it right.

Strong disagree; people can handle 10-digit phone numbers, they can handle an order 10-digit meeting ID.


Who memorizes phone numbers anymore? Just because you can doesnt mean you will if theres an easier alternate version, and a lot of the public doesnt care about security enough to not use to easier option


Who said anything about memorize? There is no universal dial-in number -- for dialling into a conference, you're provided with a phone number and a meeting code. People already can manage that much. If the meeting code needs to be 15 digits in order to neuter "zoombombing", that's not much of a hurdle or burden.


People didn’t really memorize 10 numbers that often anyway. Most people whose numbers you knew would be in a small set of area codes, or just one, and even the next three might only have a couple possibilities for most useful numbers, unless you lived in a very dense area.


If you have the same meeting every day, you will start memorising the numbers naturally.


For the phone only route, it seems like you could still mostly automate it by going oldschool. Give the host an option to play the meeting code as a DTMF signal (or whatever) while the other person holds their phone near the mic.


DTMF signal played over what exactly? The phone option is for when you aren't at a computer (driving, conference, etc..).


Maybe I'm misunderstanding the use case then? I'm imagining something like:

A and B are on a phone call. A starts a video meeting. B goes to shortlink.dtmf or opens the app, which starts listening. A clicks "transmit room code" which goes over the existing phone connection. B's client hears the signal, decodes it, and gives them a link to join.


All good points.

There is no reason why short meeting codes + 2-3 sec delay before joining + temporarily banning users who enter more than 10 invalid meeting codes in a row can't work.

There are ways to improve the security without putting on the clients shoulders. A 6 digit room code is fine if a person can only "war dial" 10 tries before being banned for an hour or so.


There's a really good reason why that wouldn't work. There's no reason why a war dialer can't create millions of users. The 2-3 second delay doesn't really accomplish much unless you limit their capacity to have requests pending.


s/users/ips/


With IPv6, I can assign myself a gazillion perfectly routable unique public IPs.


On a large enough level, this would have to be treated the same way as spam traffic currently is. You'd never ban anything smaller than a /64 with IPv6. Getting DOS from a /48 or /56? Ban them, or do exponential back-off for all IPs in the block. It's not that hard for a botnet to get a few hundred thousand IPv4 addresses either, but we haven't taken that as a reason to just roll over. The difference between each IP sending you 1 request / sec and 10000 requests / sec is still profound.


Yes, that's brilliant. That should work well when most of your customers are behind corporate NAT access points.


Thanks. Yeah, your customers aren't the ones who are going to get IP banned by wardialing.


Right, because in one case you'll see thousands of different meeting connection requests for different meetings from one IP, and in the other you'll see thousands of different meeting connection requests for different meetings from one IP.


You then have a DDOS problem


What about a long, unique identifier for the baseline, and the ability to generate temporary, single (or `n`) use, short identifiers that can be used when speaking the id?

Clicking a long I'd link takes practically training, and entering a short ID would only require training the salespeople how to generate one (would should only be a few clicks tops).

This way, a conference is secure by default and easy for people to join by link, and is still easily accessable by code for when needed.


When I think about having two different solutions for two slightly different usecases, my mind always goes to Microsoft's decade-long battle to teach their users the difference between Standby and Hibernate.

There was very real value in the distinction to those who used it, but it proved so irresolvably confusing to the vast majority of users that eventually they pulled the plug and just gave the one Sleep option.

Educating users about technicalities they've probably never thought about is really hard. Doing so without an actual training session, just through interface, verges on impossible. And if Microsoft couldn't convince businesses to train their users, I doubt Zoom can.


> striking the right balance between ease of use and security is really hard.

Why not give more "Options"?

For example when generating conference id, provide an option to generate more random digits or hash codes. When installing provide an option to customize everything. Meanwhile provide a fast and fool-proof path for rest of users.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: