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

This is what technical debt gets you.

I really don't know that zoom has a lot or much at all, but I do know that the number of viable solutions to this could be taken off the table internally because they probably made tech debt commitments in their architecture during their scale up phase that prevents bolting on obvious fixes. I have a lot of sympathy for their position. They aren't evil or bad, but they could do a massive mea culpa PR coup on the level of the netflix culture deck if they did a case study retrospective about the effect of tech debt on scale at critical moments.

It's also a product management fail, where that lack of transparency on encryption is what a project-manager would pull, where a smarter product manager would have weighed the cost of losing their e2e-crypto compliance market.

I can also see why they have security issues because today, security people are on a much longer tailed skill distribution than they were 10y ago and it's hard to listen to most of us. Getting someone to approach it as, "ok, we get that a 9-digit key is literally your product selling UX advantage, let's see what else we can do" is exceedingly rare. Privacy has massive brand implications. Remember blackberry? They launched a new flagship tablet product while their CEO got into an issue with government surveillance and the story became about their risk in India and Asian markets and not whatever that product was called. Zooms story is becoming about privacy problems too.

PMs need to be smarter about this.



I think you overestimate the reliability of the alternatives.

Zoom focused all their early engineering muscle on reliability. When we build new products, we don't have infinite resources to attack every front simultaneously. We have finite resources to prove a concept, and we incur debt in just about every other dimension.

Now that everyone is using them (precisely because of reliability) the emphasis becomes other things - UX, security, etc.

Tech debt is what the 2nd generation of engineers gets to complain about after the 1st gen made the product succesful at something.


That last statement, I'm there with you on. Tech debt is necessary, it could even be renamed "tech leverage," because that's what a lot of it is.

My thing is that there are tons of potential ways to mitigate zoombombing, even incrementally, and that they haven't or chose not to indicates it's because there were cost barriers to doing it. It has the tech debt smell, and it's what I've seen in other orgs.


> My thing is that there are tons of potential ways to mitigate zoombombing

Someone call the feds quickly, that sounds like a very serious crime.


Do any of those potential ways impact on the ease of use of Zoom? Do they make it harder to join a meeting?


There is a basic information problem, where good people have it and bad people don't. You don't need cryptographicaly strong approaches, you just need speed bumps that impose costs on specific classes of attacker that disrupts their economy of scale. It's not a secrecy solution, it's an economic nudge.

Then there are ones with vs. without user interaction.

Without user interaction:

- rate limit join attempts so that you at minimum need proxies or a botnet to guess room names.

- do a simple entropy measurement of multiple attempts and rate limit anything that exhibits symmetry or monotonicity.

- add a "correct battery horse staple" style key to the url instead of or in addition to the 9 digit pin so the link is not easily guessable, but still has the mnemonic quality for people entering it manually.

- static personal room ID's only work with a passwd/token (not pin) whereas ephemeral ones can be chosen from a much larger search space. (yes, just add entropy)

- free sessions limited to 40mins or whatever should select from a name space large enough it will take a botnet to hit even one ephemeral session in the 40min timeframe.

- separate the invite link from the login link so that session owners can specify that the user needs to click from their email invite so it gets bound to the browser, and you zoom can set a token before redirecting them to the live session.

with user interaction:

- Obvious one would be a user PIN for ephemeral room IDs.

- Next obvious would be to choose a real security protocol and key management scheme (http://www.lsv.fr/Software/spore/index.html)

Rest of user interactive ones is exercise to the reader, as those are all solved problems.

The challenge is that they require keeping logical state at the application layer, which is specifically the kind of complexity you avoid in your scale-up architecture - and it burns you down the road.


> "Tech debt is what the 2nd generation of engineers gets to complain about after the 1st gen made the product succesful at something."

Strange and snarky comment for a "Chief Technical Officer". Software constantly evolves, it's a process of continuous refinement.

Zoom's past success may have been partially attributed to "1st gen engineers" hitting the jackpot. Zoom's fate right now rests on the ability of those "2nd generation engineers" to keep the show going.


> This is what technical debt gets you.

Becoming one of the top names in video conferencing and displacing dozens of established players virtually overnight? Sign me up.


Exactly! I've built plenty of rock-solid flawless products that never got any traction. I can assure you none of them were dissected on Hacker News. Personally I'd go for getting mass adoption followed by endless free security consulting provided by the internet while it's stuck at home.


> Becoming one of the top names in video conferencing and displacing dozens of established players virtually overnight? Sign me up.

What!? That's small thinking. You could be so many greater things than that if you're willing to compromise peoples security and personal information.


I know you're being sarcastic but there are a ton of companies that have a terrible security track record and yet are quite large...


so that makes it right?


It's not technical debt, because it was not a problem before.

More likely just a poorly designed system.

Security is always a game of 'staying ahead' - with a totally new userbase context, the security parameters have changed under their feet. So now they need to quickly adapt their product to the new context.

A vastly new usage context is going to create all sorts of stresses.


>It's not technical debt, because it was not a problem before.

You mean it wasn't problem before just because it wasn't being actively exploited before? A problem is a problem regardless if is as of yet undiscovered. Or do you mean it wasn't a problem because it wasn't preventing any forward progress on the product?


"A problem is a problem regardless if is as of yet undiscovered."

Instead of thinking that a product has 'some number of bugs, which when fixed, is perfect' - consider that there are maybe 'infinity' problems. In any given context, those problems are likely to cause differing levels of concern, in different ways, and that in different contexts they may be more likely discovered than not.

For example - Mac is generally considered to be a little bit more 'secure' (heavy quotations) than Windows, the party by design, but partly because of the likelihood of attacker exploits being discovered due to limited market share.

That considerably fewer people are attacking you is a legit thing, especially in light of the potential fallout: 3 weeks ago 'Zoom' was not a pop-culture term, a breach may not have made the big news. Now, everyone's talking about Zoom, so there's a problem and Anderson Cooper is talking about in CNN, the fallout is much worse.

In this 'new context,' the calculus has changed and the impetus to fix certain problems a to maybe actually be concerned about FB login will have changed.

Case and point: SpaceX's decision to not use Zoom made international headlines. This is a huge deal. A zillion IT staff around the world are at least going to read that article. 'Software made in China' they'll read. 'Wait, what?' They didn't know that, does it matter? 'My CEO saw it on the news last night and has asked for a security review, whereas we mightn't have done one otherwise' et. al..

Edit: MY CEO has not asked for a review, I'm making a hypothetical situation here I meant to be speaking in another voice.


I feel like security is a realm where that quote is demonstrably untrue. A "hole" in your system is exactly zero problem until the moment someone exploits it.


Have a look at the current outstanding exploits on all the software you use, even 'name brand software' from FAANGS. It's scary.

Mostly all we can do is triage and it mostly works.

But I'm all for a more sound approach.




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

Search: