could xhost(1) help here?

That doesn't change that programs doing this can be shady (or very useful).

Not parent, but the web player used to be a down-graded experience from the native app. If you need Zoom for a professional setting, those functions could be important.

Do not know if this is still true, but at one point, the web player would only let you see one speaker at a time, while the app would show multiple people at once.

I notice the browser version is a little resource intensive. I use it on freebsd and I need to renice the browser to -10 for it to be somewhat stable. (This is an improvement because I remember 6 years ago it didn't work on freebsd.) I ran it on a Mac last week and it spun the fan more than I'd expect.

I recently had to use the browser and was shocked to find there was no option for Gallery View. You were just stuck with one square in the middle that would bounce between different faces. I feel like they have the worst web experience out of all the meeting apps.

99% of the time I use the browser.

However, the video quality in the browser is worse, so depending on the use case I might have to use the app (via sandbox).

It's been years since I've had to though.

I always try to use browser versions of things, but zoom just hasn't worked for me in it for changes. No error messages or anything, just insistence on downloading the app. I assumed they got rid of it but I guess not.

I worked at Zoom during this time. That's not what happened.

Zoom used the same technique Cisco Webex did - they ran a webserver with an open port so that local "links" to a meeting could open on your own machine. It wasn't a backdoor. Apple flagged that as a potential security risk, so Zoom worked with Apple on how to safely remove only the webserver without affecting other functionality. We were happy that Apple worked with us on this.

However, I thought it was very interesting (and strange) that there was almost no reaction from the tech community that Apple had software running on every Mac that allowed them to remove any binary they wished. (Which sure sounds like a backdoor)

Unfortunately making software easy to install also makes it easier for Malware to be installed. It's a classic dilemma that is only fixable by making the user think twice about running stuff from the internet: Unix requires making the file executable, Windows at some point started tagging downloaded files with an "untrusted" attribute.

The web client definitely lacks features, but I fail to see how this is a client feature? You can share your screen and have your camera on at the same time. It's the recording server that decides how to composite those together.

You could do much of that with OBS and its virtual webcam, passed to the web client. It's a minor hassle to set up the first time, and is ready to re-use thereafter.

I have a few scripts that interact with wl-copy. Like one that just cats all the files in a directory and pipes it into wl-copy so I can paste it somewhere else. Something like that would've been immensly useful when I was still on windows, but that would've been too much a bother to set up.

Snaps are a lot lot better in this regard especially in the perspective of connections.

You can define connections to home, camera, network etc...

I have not seen the same in flatpak.

Actually we should have something like iOS in which you can allow an app to access certain images (or whatever), or manage the images it generates.

Jokes on you, systemd-appd is in planning stages right now.

systemd-clipboardd? What could be better!

We use a lot of sip with all manner of endpoints

Slack has a button you can use to add custom emojis. Mic drop.

IRC the protocol is pretty good still, specifically with the ircv3 additions. It's the clients that are janky still. I still remember when Slack ran a free IRC bridge for their chats...

And that is useless if you have meetings with people that "have standardized" on Zoom, and that hold some sort of leverage over you, like clients/customers.

I dumped it after realizing Xen does its damndest in preventing you from hiding VM attributes from Guest OSes.

Proxmox uses KVM, and is easy to configure a VM to make the guest think it's on bare metal.

In the proprietary software space, a LOT of things run badly or refuse to run, or license stupidity with a guest OS. So for me, spoofing bare metal is an essential part of running ilk like Windows and proprietary apps. And also, school remote testing garbage.

Depends on how you use your computer. If you're mostly a developer/analysis terminal jockey with some browsing-- Qubes is a tremendous upgrade even if you don't care at all about the security properties:

The normal qube model of template OS vms + ephemeral app overlays makes it a cinch to troubleshoot complex issues because you can scribble all over the VM (e.g. go ahead, monkey patch your system LIBC if you want!) and all those changes will be gone when you restart the VM. Once you do find a solution you like, you can apply it cleanly and intentionally to the template. If all you were doing was a one-off, then no need to go make it permanent. Not sure if the latest Fedora upgrade is going to break stuff you care about? Install and switch to it one appvm at a time. Something breaks, file a bug and switch that one back until its fixed.

I've had friends screwing around with AI agents get their systems really screwed up because running the agent in a VM was work and requires maintenance. .. in qubes its just the natural way to run it, a few clicks and you're good to go. And the maintenance overhead of running in a VM is mostly non-existent.

If you ever use VPNs for privacy or to access protected networks-- Qubes is a big upgrade: You can run multiple VPN network VMs and then pick on an AppQube by AppQube basis which network they use. Then you don't have to worry about malware from your reddit browsing VM (or your Erotic MLP fanfic) going out over your employer's network or your banking going out via some Norwegian anonmization proxy that might spy on your traffic or cause your bank to instantly block your account. You can accomplish this without qubes but in qubes its particularly easy (and easy to get right): Every VM that has network access has it provided by another VM. Configure the networking how you like in that service VM and then pick what uses it.

When I say 'developer' above I don't mean to suggest that Qubes is particularly hard to use-- as I know significantly less technical people who use it without issue. But its non-security/privacy advantages are most significant if you're doing experimentation with the computer's configuration.

However if you're doing stuff that is Video heavy-- particularly gaming, and to a lesser extent CAD, video editing, etc. Qubes really brutally hurts video performance. It can be somewhat offset by running on higher end hardware (and then getting performance of a few year older system). Even just watching youtube videos is obvious impacted.

Similarly, it dents battery life. This is addressable via additional batteries given that now laptops are usbc powered and 100wh external batteries are readily available. But this is something of a lifestyle question.

Even before the AI-apocalypse I considered qubes to be non-negotiable on laptops-- there are just far far far too many browser RCE vulnerabilities to consider anything less for any computer that isn't a total security write-off.

Previously if I followed a link to a sus site and had my browser crash (maybe even the day before a RCE-in-the-wild was announced). I'd have some rationally justified paranoia that my whole computer might be compromised. Now, I can close the app VM (or-- better-- toss the disposable, which I try to use for most browsing) and know that even if they exploited the browser they'd have to have a VM escape of some kind too to do me any lasting damage.

The highest security stuff still ought to be on isolated hardware, of course. But using a multipurpose computer without qubes is unsafe at any speed, worse than driving without a seatbelt.

In the last couple of years, my only contact with Zoom is the scam webinar invitations from month old domains.

At this point I probably wouldn’t realize a legitimate Zoom meeting was legitimate.

https://news.ycombinator.com/item?id=49677401

Spinning up a conference host for a small office is fairly trivial =3

https://jitsi.org/downloads/

Or just use Google Meet on all browsers, which is more practical to use than Zoom.

Zero software to install.

That's very telling about the quality of the security audit.

Unfortunately, we are living in a world where we need to treat every third party application that we run (and in some cases, even the operating system itself) as a hostile attacker.

Gone are the days when you could download a software, run it, and trust that the developer isn't transmitting everything on your system back to their servers. Developers have poisoned the well and repeatedly demonstrated that they will run roughshod over the user's system, send telemetry back about everything the user is doing, enroll them in A/B experiments they didn't ask for, and take advantage of every resource, every peripheral and device, and every bit of personal information they can get their hands on.

Unless you are 100% running open source software that you have personally vetted, or that you trust that the package manager / maintainer has sufficiently vetted, you can't copy a password into the clipboard with any kind of confidence that other apps aren't sneaking a peek.

Let's assume I have control of my own computer. On this computer with Linux and X11, how do I restrict programs (such as Zoom client) from accessing the clipboard?

Narrowly, I don't think there's any technical reason why a better clipboard couldn't require the user to specify where to send text ("paste content into application X field Y") and then handle transmitting that data on the user's behalf. That way, the clipboard wouldn't be readable global state without intent.

The paste intent doesn't seem antithetical to accessibility. A keyboard combination states intent just as effectively as a voice command, mouse input, or other source.

Accessibility apps naturally require privileged access to other applications. Using the clipboard for accessibility is a hack though, as its intended purpose is occasional generalized data transfer. Also, Zoom isn't an accessibility app in the first place, and all capabilities it needs should be opt-in.

What are you going on about? Why shouldn't there be some temporary authorization prompt for clipboard access? You could even wire it up to control-V somehow such that the same keystroke would grant temporary access and communicate a paste to the application. Nobody is talking about making the clipboard unusable.

Outsource trust more carefully.

> Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware.

But this statement basically says: "Linux has no good permission controls for running software". The assumption is flawed. Trusting software is not a true/false thing.

Yes, you can use sandboxing tools, but how many people use them properly? How many usability bugs do they still have?

Thankfully iOS rolled out a permissions prompt for this. Pretty illuminating just how often other apps read the clipboard, e.g. Google Maps reading my clipboard every time I tapped on the text field to search for a destination.