On the face of it this sounds fair, but the problem is that being "sceptical" and "realistic" is far easier and requires much less effort than being "visionary"[1]. Too much of the former early on can really suck the life out of a team, increasing the risk that the product fails, or is simply never built.
Safeguarding from abuse is much better achieved by systematic thinking and discipline (which are learned skills) rather than hiring "realists" who might simply turn out to be whiners and energy vampires.
As much as Zoom is currently in the spotlight, and I can't say I'm overjoyed by a number of the issues I've read about (e.g., encryption keys being passed through Chinese servers?!??), many of them are the problems of success, and every successful company has or will experience their fair share of those.
[1] I might also add that it's far easier to commentate and to critique than to do, eh, TechCrunch?
Let's be clear: The issues that Zoom is having were seen by other businesses in the same industry decades ago. At a time where every other messaging system in the world has been moving to end to end encryption - even facebook, Zoom is still lying about it to customers. It doesn't require a room full of sceptics to figure that out, it requires some sort of development process that involves a the tiniest bit of thought before rushing out a feature - a culture that is apparently consistently lacking in large parts of silicon valley.
Btw, If you think that what we've seen over the last few years is that commentating on tech is an easy career to make a living at, you haven't been paying attention to the state of journalism.
The comment I quoted by TC was clearly intended as a general point with broad application across tech companies, not just Zoom. Now either TC meant that, in which I disagree as outlined in my previous comment, or they didn't, in which case it's sloppy phrasing and journalism.
> Btw, If you think that what we've seen over the last few years is that commentating on tech is an easy career to make a living at, you haven't been paying attention to the state of journalism.
I said it was easy to commentate or critique (it is, and it happens on HN all the time). I didn't say it was easy to make a career out of it nor, frankly, do I think it should be. There are far too many lazy, bottom-feeding media outlets in the world and not nearly enough good ones, so I will not shed a tear for the demise of the former.
To address your specific points about Zoom: it is demonstrably false that "every other messaging system in the world has been moving to end to end encryption".
Microsoft Teams does not implement end to end encryption for audio or video meetings because they can't: they support dialling into meetings using the plain old telephone system meaning that the back-end services become an endpoint and have to be able to decrypt traffic. Sure, Teams could do it for text chat (and it's even a suggestion on UserVoice: https://microsoftteams.uservoice.com/forums/555103-public/su...) but, as far as I'm aware, they don't even do that yet.
Whether that's a big deal or not depends on your use case.
That Zoom lacks E2E encryption is not the problem: that they claimed to implement E2E encryption when they don't is. Contrast with Microsoft, who don't claim E2E encryption for Teams and, as a result, there is no significant controversy.
Some people and use cases do need E2E encryption but, for many, the trade-offs aren't yet worth it.
As already highlighted you lose support for POTS, which in my experience is used pretty regularly: e.g., people on the move, or dialling in from outside the organisation.
Another example: I suspect E2E encryption would make it difficult, even with modest numbers of participants to implement Zoom's gallery view because they'd have to send all encrypted streams in full to all participants, and clients would have to decrypt and decode all video streams. Even if it didn't prove overwhelming from a bandwidth perspective, it would eat CPU and drain battery life very quickly. Without E2E you can decrypt and multiplex on the server side then re-encode and re-encrypt to reduce bandwidth usage over the network and resource usage on clients.
Of course, this isn't insurmountable: clients could send two encrypted streams, one hi-def, and one for gallery view, and the server could route them to clients as appropriate depending on their viewing preferences. Still, this probably isn't as efficient as dealing with it on the server side.
(Obviously you might not care about gallery view, but it seems really popular for remote social gatherings.)
It's all about trade-offs: for virtual pub with my friends, I don't really care about E2E encryption, but gallery view is really great. I don't even care about E2E encryption at work that much - certainly not enough to make it more difficult for people to dial in to meetings.
But, as I say, none of this is the issue: the issue is the claims Zoom are making about their product.
A team full of visionaries will never get anything shipped at release quality. I've worked with plenty of them. You don't need to hire a bunch of depressing pessimists but if you don't have skeptics and realists to keep your team's velocity under control you're never going to hit quality targets.
Imagine there being multiple valuable skills in an industry, like critique, commentary, planning, debugging, testing, engineering, design, and ideation!
the best visionaries (musk, bezos; not zuckerberg, thiel) combine idealism (hey, look at what could be!) with skepticism (hmm, why wouldn't that work?) to push the boundaries of invention.
A meeting id with a password is semantically the same as a longer meeting id (or a meeting id with a character space larger than just digits). I wish they'd do that instead (make meeting ids longer) so I could continue to enter my company meetings with only a link but not have to worry about getting wardialed.
https://tenant.zoom.us/j/123123123?pwd=QlR0cXZkYXBDS0txYzJRR...
The password is an encoded version of the password set by the host.
With the most straightforward way for "meeting id with a password" and "longer meeting id" to be the same, both methods provide the exact same expansion in search space compared to the previous implementation, and they have the exact same search space as each other.
(That method being: concatenate shortid and password to get longid)
I'd think more eyes on Zoom right now will be better for it in the long run. Anecdotally, security aside, I've found Zoom to be about one step ahead of BlueJeans in pretty much every way.
That being said, the AV quality between the two are pretty similar.
I'm using Jitsi now and am quite happy with it.
I also do not believe that it claims to have E2E encryption or anything like that.
we've had a few glitches here and there but overall highly reliable. The ability to do a meeting or do an event to prevent zoom bombing type issues is wonderful.
As for the Zoombombing, I can’t say that I am surprised. All you really need is the URL.
And all the other tools are like that too. Sure, you can require a separate passcode, but damn it, it’s like trying to figure out rocket science to enter the passcode.
1) you have to dial the number
2) you have to punch in the meeting ID
3) you have to punch in the passcode.
4) ERROR. You flipped it, and used the passcode for the meeting ID instead. Aargh.. frustration.
5) Forget about the passcode. Just let everyone in that has the meeting ID. And monitor if there’s someone unknown on the line.
It must have been at least a decade since I actually dialled into a video conference using a phone, on any conferencing platform - I always connect audio via my laptop or phone, which I use with a Bluetooth headset.
I was actually having this conversation with a bunch of colleagues the other day, and every person in the call said the same thing, only difference was some used a USB headset, rather than Bluetooth.
Universities typically have SSO, so this don't seem like a hard thing for them to implement.
At the minimum they could show anonymized email id: ab<..hidden..>gh@univname.com
She didn't follow the recommendation because she "didn't think someone would join" because she hadn't posted the meeting link on social media. You have you protect your users that won't protect themselves.
Would this be solved by generating chat names through a cryptographic hash algorithm?
I have google docs that are edible by anyone with the link and I’m kinda assuming that the link is as hard to guess as logging in with a password.
Am I completely off and in dire need of reevaluating my personal web security?
