Hacker News new | past | comments | ask | show | jobs | submit login

One positive thing about all these horrendous security flaws that have been recently discovered in Zoom, due to its popularity, is that the company seems to be taking them seriously, recently instituting a feature freeze to focus on fixing them: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u...

As a consequence, I suspect Zoom's security is more likely than not to improve going forward... although it will surely take a long while. Security is Capital-H Hard.

Also, I cannot think of any other multi-video-conferencing solution that "just works" and has been as thoroughly stress-tested and attacked by bad actors in the wild at such a large scale. If Zoom does a decent-to-good job fixing all the security issues, it looks likely to continue to dominate its market.




I'm not a fan of Zoom... But the pile-on of grief is ridiculous.

The "war dialing" issue is a great example. Webex has had the exact same "flaw" for a decade, with the exact same solution - set a meeting password. Other solutions like Google Meet or Skype have the "lobby" approach.


Fun fact - perhaps not widely known and perhaps why it shares a similar philosophy as Webex:

Zoom was founded in 2011 by Eric Yuan, a lead engineer from Cisco Systems and its collaboration business unit WebEx.[1] [1] https://en.wikipedia.org/wiki/Zoom_Video_Communications#Hist...


I've always wondered about spinoff startups like this from larger companies: aren't there usually non competes that would prevent them starting them?


They're generally not enforceable in California, provided you're not making use of any protected IP or what not.

https://casetext.com/statute/california-codes/california-bus...


They're not usually infinite. My father waited one out for three years, then went back into the industry for a rival firm and put his old boss out of business.


Isn't it easily fixed by making IDs slightly higher entropy, and also rate limiting retries? Something like a Youtube ID which is 11-char in Base62, which is short enough but has so much entropy that even know with billions of videos, entering a random ID will most likely not work.

You should also always have some reasonable rate limit of any sort of API query, if someone is querying rooms at 10qps or more, there's clearly something wrong.


I wouldn't be shy about betting the reason they haven't done this is because they don't want the ids to be longer/have a larger character set than they have to be, because they'd take longer/be more error prone to type/say out loud. Lowest possible friction: the reason for most of their flaws thus far.


Agreed.

I will add: security and convenience are always polar opposites.

The most successful companies are typically the ones that can get away with being as convenient as possible for the longest.


I would disagree about "always" polar opposites. For example SSO/iDP like Okta add a ton of security but also makes it easier while more secure for employees to log in to their multitude of company apps.


I think the catch is that people only notice when they're opposites. If making something more secure also improved the usability (or didn't harm it), then things would (generally) be done the better way. It's only when there's tension or compromises to be made between the requirements that we actually see it, and start to think that they're opposites - because in those cases it is.


An excellent point, and I’m hoping some examples come up to show that convenience and security actually can be in the same direction.


While I agree that things like SSO can be more secure and more convenient for the user, that doesn’t actually make them more convenient overall. In your example it’s mainly the fact that Okta has abstracted away the complexity so that businesses don’t see it.

I’m open to being proven wrong, and as eythian implied, I may in fact be subconsciously cherry-picking times where security and convenience were opposites and missing times where they were not, but even with that awareness no counter examples are coming to mind.


A phone number is already 10 digits. As long as you put proper break characters between the groupings it's not hard to read IMO.


They could also just generate 4 words and string them together as the password. Considerably more entropy than 10 digital and easier to communicate too.


You need the ability to enter the code on a numeric keypad when dialing in from an office phone. Compatibility with "ancient" enterprise practices is also important.


Why not a word-based code for most people, and a numerical one for places that need them (can be enabled/disabled in the tenant), and only allows for phone connections?


Ah, that makes a lot of sense. I'd never considered that!


Using american-english dictionary from aspell [1] and filtering for lines that only contain lower case letters [2] gives you 77649 words. For four words that gives approx 64 bits of entropy [3].

[1] Probably available on a Linux system at /usr/share/dict/american-english

[2] '^[a-z]+$'

[3] log_2(77649^4)


Kind of like the what3words approach to GIS

[1] https://what3words.com/about-us/


This is exactly what jitsi does


English-specific tho


Not hard to do it for any language. And they're cheap to make.

    Your memorable phrase is 'correct horse battery staple'.
    
    <copy>     <generate new phrase in $LANG>
Its not often that people without a common language have zoom meetings anyway


Zoom meeting ids have to be enterable in the phone bridge


speech recognition's probably good enough if you pick your dictionary well


Across a range of accents and such, I'd be surprised.


IMO, when it comes to security, the fact that other people have made the same mistake makes a design flaw more egregious, not less.


It’s not an egregious flaw, any more than the telephone numbering system is. It’s a design decision to improve usability that is generating a lot of noise during an extraordinary period.

Usability is the zoom priority, and the reason why people who already own more secure, no cost, solutions like Teams, Skype or Google Meet buy Zoom.


Knowing someone's phone number very obviously doesn't grant you direct access to autojoin their calls with people. At _best_ you can attempt to tell if they're currently in a call or not by calling them, but even that is far from reliable (e.g. in places where voicemail isn't as much of a thing do not disturb is sometimes implemented by pretending to be busy or switched off)


People often forgot that its a Security-Usabilty scale, with perfect security on one side and perfect usability on the other. An unplugged computer is perfectly secure, while a computer wide open is perfectly usable. But neither is usually preferable.

As with most things, its a trade off.


That is absolutely not an information security norm. Most security mistakes fall into common patterns.


Zoom in fact also allows you to enable a "waiting room" for all meetings owned by your account.

It's not always ideal though. I've organized meetings with 10+ people, want able to attend the meeting and now nobody can join the session.


I'm not sure about this, but there is a way to make someone a co-host who could then presumably make those decisions?


So there's two kinds of problems here - not all security flaws are created equal.

One kind is missing something or unintended consequences. Making all URLs clickable opens a UNC attack due to some obscure Windows "feature", for example. Or having N digit numbers means they're technically iterable, but this is the same for cellphones, and there are workarounds.

The other kind is security holes caused by explicitly working to bypass security restrictions yourself. Installing a server with webcam permissions that you don't cleanup so reinstallation is easier for you (don't be surprised when other apps start telling it to switch on the webcam), impersonating the system root password dialog (don't act surprised when other apps steal the password from you), claiming end to end encryption without being clear about where and when it's on, and others.

The first is normal security work, the second is sleazy. We all forgive the first, but we shouldn't let sleaziness slide.


Why do people keep saying it just works? It just works if you install their app, probably. But audio doesn't work at all in Firefox. That's not really just works for me.


I'm not sure about "just works", but I am sure about "works" in the sense that is head and shoulders above every other video chat app I've used when it comes to audio and video quality, especially for large numbers of participants, audio sharing, document camera sharing, multiple participants sharing simultaneously, and there are plenty more.

I've never used the web version, but it wouldn't surprise me if it's not the same experience. The video and audio encoding and decoding stuff seems like it just makes more sense as a native app. Given the number of variables that browsers, versions, sandboxing, etc. bring to the equation, I can tell you where I'd spend the majority of my efforts if I were doing video chat: on a great native app. You have a lot more control over that experience, IMHO.

Anyway, your comment reads to me like someone who will never install it, but I would encourage you to at least test out the difference to see why it's become so popular.


Yeah, the only other video app I've used that approaches the call quality is Slack. I've not tried to use that with more than a handful of people though.


Slack would be great if my team didn’t constantly have issues with it dropping audio or video altogether when attempting to connect, and that’s if the connection works in the first place! A shame, because we’d love to use only a single app for our comms...


Slack was by far the worst of all the ones we tried.


For every N users that say something works, you will always find M users that say it doesn't. For good products the ratio of N:M (works:doesn't) is high in the direction of N (works).

So people keep saying "it just works" because Zoom has a noticeably high ratio of works compared to almost any other video conferencing software. It does not mean it works 100% of the time flawlessly for every single user ever always and forever.

FWIW, of the hundreds of Zoom calls I've had, many with non-technical people, I have yet to encounter any issues. I cannot say the same for most other video conferencing products I have used. YMMV, take with grain of salt, caveat emptor, etc.


Yea, Hangouts is a lot more "it just works" than Zoom is for me. That being said, the quality of the actual calls on Zoom is _way_ better than Hangouts.


I mean, I don't really know how "consistently high call quality" is not the most important feature of any video chat application. My experience on hangouts has always been garbage. Delays, choppy sound, my machine starts going insane while rendering other people's live video. It may just work in the sense that you can immediately use it, but if even 20% of the time you use it the call quality sucks, then it's a crap product IMO.


> It may just work in the sense that you can immediately use it, but if even 20% of the time you use it the call quality sucks, then it's a crap product IMO.

"it just works" doesn't mean "its a superior product". I use Zoom over hangouts whenever I'm on a call with more than ~3 people, but automatic gcal integration + being fully functional from a browser means that hangouts makes more sense sometimes.

(I also don't have nearly the amount of issues you do with hangouts. The biggest problem for me is how much worse they handle crosstalk, which isn't an issue when there are only a couple of people on a call.


Is Hangouts now the same as Meet, or does Google have two different products? Hangouts used to work fine back when it was integrated with Google+ (I miss those days), but I just tried to go to a meet for my son's school, where nobody could see or hear us, and Meet claimed the mic was muted by the system, while the system said it was turned on and the browser had access. That's clearly not "it just works", but apparently nothing is.


[flagged]


Aside from the fact that you're wrong, I think you need to take a break from the internet. You seem stressed.


Aside from the fact I'm not wrong. I think you need to source and/or explain your unfounded claims:

Google Delays Hangouts Shutdown Until June 2020

https://www.extremetech.com/internet/297037-google-delays-ha...

WebRTC Internals in Chrome with frame rate capped at 5 FPS while screen sharing:

https://www.reddit.com/r/chromeos/comments/absxt2/chromebox_...

Screen Share through Hangouts/Meet with high FPS? R: Nope

https://www.reddit.com/r/chromeos/comments/fo60me/screen_sha...


hangouts meet does 1080p (whether it works now during the covid pandemic I don't know) and is Google's replacement for the regular hangouts. it has been available for companies and has been part of g-suite for enterprise since 2017.


Where I work, it defaults the webcam resolutions to 360p and we can only choose 720p for our 1080p hardware.

Anyway, my biggest concert is with lack of fluidity of slide/screen sharing.

It is not viable for presentations with animations or where the presenter needs to point with mouse/cursor to a specific point or area of the slide (for example, a point in a curve in a graph).

I work with this.

I'm struggling with this tools first hand. My impression is there a lot of opinions here from people which is not using these tools.


I think that in most VTC platforms, the tendency is to favor quality/resolution for screen sharing and speed/FPS for camera sharing.

It sounds like your case is less common but the idea is that a video or camera feed can handle more compression (and subsequent drop in quality) as long as it isn't choppy or dropping out. Alternately, a slide or document may have small text which would quickly become unreadable if the compression is too high. To prevent that, you get high quality but only 5FPS or whatever so people can read your document or slide.

Slides and docs don't usually need high framerates so it would just be wasteful to try delivering a mostly static, high resolution, low compression 1920x1080 feed of a PowerPoint at 15 or 30 FPS.

There are ways around this (even on a consumer PC) such as using something like OBS to switch between sources like a webcam, a video clip, or a screen cap and feed them to a virtual webcam (which can be selected in your VTC software as the webcam input). Alternately, there are dedicated switchers and mixers but they're usually reserved for studios or in-facility installations.

But again...you may not like the results even so. The webcam feed often trades higher FPS for higher compression.


This is likely why they really push you to install the app, rather than use the browser version.

They have a lot more ability to ensure it works when it's their own binary. When you're relying on a bunch of browser functions, it's way harder.

The browser version is a last resort.


Neither does Webex's browser version - even though I give it permissions, audio requires Webex to call me.

Latest Safari/macOS.


We've run into a lot of this lately as well (working in a university supporting online classes for the past week or two). I know it's not ideal, but Firefox and Chrome don't seem to have this issue. Asking someone to use a different browser is annoying, but it's a workaround that seems to be effective so far.


> Security is Capital-H Hard.

It is even harder when you try and graft the security on after the fact. Security needs to be a consideration from day 1, not once youve your minimal product. Proper security may steer architecture decisions that may be difficult or impossible which to adapt. This is especially true for internet facing services.

I had a hell of a time bolting on authentication/permission to an internal API (not web based) at a previous employer. By the time I left, we had all users authenticating, but only maybe 20% of the API surface had permissions beyond being authenticated. It was a CRUD API over +300 objects. Yeah, everything was audited, so we couls recover from a malicious or bumbling idiot authenticated user, but the exposure was way to high with people having far more access than their roles needed. It was a mess.


Yeah... graft it on after you've lunged to make a sort of OK product and they're locked in but the vulnerabilities you're exposing them to aren't worth moving off the platform. The capitalist sweet spot


Your comment reads as an alternative form of “This is good for Bitcoin.” where its most rabid followers see nearly any news, even disastrous, as being good for it.

You are saying because they had lax security, now they will have good security.



Pro: A worldwide, motivated, unpaid volunteer team is doing their thorough security audit, privacy review and QA testing for them.

Con: After the product was released :)


Jitsi "just work" and is much secure (https://meet.jit.si/)


>Also, I cannot think of any other multi-video-conferencing solution that "just works"

Another post about Zoom, another comment how it's the only video conferencing platform in the planet that "just works". You know I find that really hard to believe... not least of all because I personally use other solutions without never having major hiccups at all.


Ok. This was way too funny. Linking to a wordpress blog about their focus on fixing security bugs.


Yes now Google meet uses random alphanumeric meeting ids this helps for sure you needed to find the.balance between security and accessibility.


>horrendous security flaws

You’re kidding... right?


>recently instituting a feature freeze to focus on fixing them

Or they're having productivity problems like every other company right now and are spinning it to seem like they are on top of things. These security issues have been around for years.




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

Search: