I always ask (1) why does an app require installation and (2) why would it require root?
There are valid answers for both, but realistically, all a videoconferencing app should need (apart from audio and video and maybe screen sharing) is to store a config file.
There's no legitimate use for it accessing privileged or private paths.
On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.
I think the only possibility that comes to mind is creating an ebpf module that sandboxes all filesystem calls and trampolines all ld_open calls.
But then you would have to provide massive amounts of patched/"safe" variants of all kinds of shared libraries which is unfeasible.
But I mean in the xorg use case it would be possible to just provide your own library that fakes the expected returns and sends fake data to the sandboxed applications.
I did a similar thing with barrier (though using LD_PRELOAD, see [1]) on my debian system to force a different behavior.
Source: Am kind of experimenting with ebpf a lot for that use case. C ABIs and SO files are a mess though. A real messy mess.
Not really - it's not sufficiently fine-grained and, besides, you need it to connect to X to display anything.
There were various attempts to improve this situation in the early 2010s, typically using Xnest or Xephyr in conjunction with other sandboxing techniques. I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention.
The fact is that the X model was never designed with these threats in mind.
> I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention.
Not sure what you are talking about. Qubes offers reliable protection with decent performance, unless you work with graphics. See also: https://news.ycombinator.com/item?id=49678250
How so? If you can break out of a sandbox then by definition it is not a sandbox.
There are ways to force sandbox jail. For instance, giving processes only a partial view of the computer system. GoboLinux did this years ago via ViewFS (https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-... search for ViewFS). There are many other similar solutions, some probably better.
Out of interest why do you still use the app and not just use it in the browser? I feel much more secure having it in the browser sandbox and everything I care about works in the browser.
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.
Well this was back in COVID, sometime fresh after the always-open-port news had surfaced. Can easily believe the experience has been improved since then.
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.
Last time I looked at their web client, it was indeed doing absurd things (I think it used TCP and web sockets to carry video instead of WebRTC and shipped a WASM video codec that obviously can’t be GPU/hardware accelerated).
Not sure if that’s malice (to nudge people towards using their invasive desktop app) or incompetence.
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.
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)
Apple did block the app so the 'working with Apple' didn't exactly earn Zoom a lot of trust with them otherwise they wouldn't have done it. They'd have let Zoom fix it in an update. And just make that update mandatory. They were just looking out for their own customers in limiting the impact, but for them to pull this handbrake means they really saw this as a big risk.
'But Cisco did it too!' is just whataboutism. It was shown to be exploited (IIRC to open scam websites) which was a real backdoor and a legitimate security risk, not a potential one.
This is something that should never have happened in the first place. Even releasing something like this in the first place is really showing no concern for the security of customers at all. What it looks like to me is that zoom wanted to conquer the market by ease of use and was willing to sacrifice security to do it. The zoombombing thing was another example.
And yes Apple has an emergency brake for malware outbreaks. And they've only used that one for high profile apps once, for zoom. They didn't do that lightly, especially during the pandemic when people were depending on it.
Really I have no good words for the actions of zoom. And there have been more incidents.
I was involved in mitigating these screwups in my work, what we did was flag zoom as malware ourselves so it automatically got removed from every company machine. And block it from being installed by the user. This block is still in place.
Ps I'm sorry if I sound harsh but zoom has caused several security worries at work and we don't even use it.
A whataboutism that makes a legitimate point. It isn't reasonable to dismiss something just because a person makes a comparison. It's valid to consider that Apple might have been applying inconsistent standards and unfairly targeting Zoom for some reason.
I doubt they were being unfair but it is a bad practice to dismiss an argument because someone has the temerity to expect consistent standards. The threat of Apple arbitrarily removing apps based on unreliable reasoning is concerning.
> Ps I'm sorry if I sound harsh
Actually, thanks, that did go a long way.
It's not whataboutism, I'm not trying to distract from the point, I'm saying there was _prior art_ in the industry where customers appeared to tolerate this.
There was another PM on the team who felt the same way I did and we basically both wagged our fingers and said "you should have asked people during install", but who cares, it was too late.
Zoom had, I will say, a very... Chinese culture around software security. If you're familiar, Chinese software is often much more interested in just getting the job done in a simple way, and security is... not the job? I've used a lot of Chinese software that just wants full admin everything so no one had to learn about permissions.
Zoom wasn't exactly run that way, but the pool they hired from had a lot of that mentality in it.
I thought Apple's tool was ridiculous though. It's like "oh, some trash blew into our yards from the neighbor's trashcan" so Apple replies "oh, don't worry, I destroyed it with my orbital ion cannon" and the tech community never stops to wonder if maybe it's a little strange that Apple has an orbital ion cannon and maybe we should ask some questions about the ion cannon.
Asked people what during install? From my perspective this should have never been designed this way. I understand if you're a PM, but those engineers should've known better, Chinese or not.
As for the ion cannon (signed and notarized apps) people do talk about this and question it. Apple's infamous walled garden. Europe is trying to fix this with the Digital Markets Act (DMA) and the USA is trying to fix this with the right to repair.
But you have to admit, in this instance with Zoom, it was used for a just purpose. Apple protected end-users against bad code from Zoom, which from your post, seemed complacent.
> I thought Apple's tool was ridiculous though. It's like "oh, some trash blew into our yards from the neighbor's trashcan" so Apple replies "oh, don't worry, I destroyed it with my orbital ion cannon" and the tech community never stops to wonder if maybe it's a little strange that Apple has an orbital ion cannon and maybe we should ask some questions about the ion cannon.
Nah, that's very on brand with Apple. The Apple ecosystem is well-known to be a walled garden where they rule and are very stringent about separation to the outside and being in control. People who use Apple products know what they are getting into.
> 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)
Because that’s a documented feature (malware protection).
As a user, I generally like it, and in this case I’m fully aligned with their classification of Zoom’s behavior as a nuisance. A lot of malware developers justify their behavior as “just doing what their users want/need”.
> A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end.
> There's no legitimate use for it accessing privileged or private paths.
Well, that was the whole premise that made Zoom popular in the first place! It was a true one click install which made onboarding frictionless for non-technical users
Security wise, it's insane but user experience wise, it was unbeatable and is what solidified their position. It's ironic nowadays that all of those tricks have been stripped away, making it just as painful as any other platform to install on a fresh machine.
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.
Just run these things in your browser. Despite the dark design patterns that try to trick you into installing their desktop client, the web-based versions are fine.
not if you have to host meetings! the web versions are feature incomplete and don't support something as simple as screensharing with your camera overlayed in a corner (essential for recorded meetings).
the zoom linux client consistiently locks up my entire computer whenever i copy from the chat. ridiculous.
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.
it's a client feature because zoom is terrible. you composite camera and screen on your end so viewers see it on one screen, and the zoom cloud recorder records only one streaming source at a time. without third party integration i cant save my camera feed and screenshare at the same time in the web version. it's terrible.
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.
nope, because if anyone else talks the focus then shifts to them and nobody can see your screenshare. you have to instead use obs' popout preview and screenshare that specific window, which doesn't work if you dont have a second or third monitor due to always needing to be maximized.
> I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam.
This sounds very useful. Is the tool available anywhere? xclip -loops doesn't seem to do the trick, or maybe it just doesn't work that way on Wayland.
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.
I wish most Linux distributions had something like a standardized permission manager in which you enable the single policies apps are running with, similarly to what happens in Android (that has some Linux stuff under the hood).
How hard would it be to have something like this? And I can’t even imagine the difficulty of gathering together the whole community around this standard...
> How hard would it be to have something like this?
Very.
Both because of the technical issues others in this thread mentioned, and because Android and iOS had the unutterably massive advantages of starting from zero pre-existing software and having a single controlling authority.
The controlling authority allowed them to avoid problems related to consensus or people working on other priorities. Starting from zero allowed them to not worry about existing software (the closest thing to a controlling authority that Linux has cares a lot about backwards compatibility).
Quite hard because on Linux there is no concept of "apps". There is a (very flimsy) separation between processes, but the strongest actual security boundaries are between kernel and user space as well as between users. Namespaces are explicitly not acknowledged as such, which limits the security guarantees that containers can provide.
Snaps and Flatpak are steps towards that goal, but there are many issues surrounding these technologies, and many apps require sweeping permissions to work well since they were not initially designed to be limited in that way.
I don't get why a big company like Zoom, with presumably lots of users who are on Linux, only gives us a .rpm/.deb instead of a Snap/Flatpak. Seems like doing the minimum.
I would rather have a nice popup on first attempt "this application is monitoring your clipboard, allow?", ideally with that process completely suspended while that prompt is up.
This should be behind a toggle driven by intent, rather than something allowed by default. Default stance on trust should be "don't". Open source has nothing to do with it, when a typo while installing with a package manager means you might accidentally install something else (a common attack vector).
Sure, in a way SIP is bigger than ever with NGNs, and there’s SIP use beyond that too, but actual interoperable SIP (as in, I can dial sip:name@example.com) is effectively not a thing anymore.
I don’t deal with corporate telephony but our sip accounts on the broadcast side have all manner of endpoints, including software and hardware from many different manufacturers. We land them on a pair of paired oracle sbcs which somehow (I’m not close to the details on this part) shares account detail and sessions between the two geographically resilient locations.
I do believe that vendor-interoperable SIP exists today, but I also know that I can't call >99.9..9% of the people in the world via SIP, and 100% of the ones I practically do call.
This is a very different story from e.g. email – even though most people I communicate with use either Gmail or some hosted Outlook service, I don't have to on my side (with some limitations around deliverability etc. lately).
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...
if you use Wayland's security context to prohibit privileged protocols such as arbitrary clipboard access then an application will either not be able to grab clipboard content until you focus on it or the attempt will be noticeable as it spawns a short lived window in an attempt to grab focus.
Apps generally need not get clipboard contents unless focused on right? Like this should be the default in my view and kinda disappointed it isn't for Wayland.
For most normal meetings, this is the way to go. However, meetings that have hundreds to thousands of participants (corporate all-hands, investor earnings calls, etc), I just don't think it scales well enough.
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.
University of California has licensed zoom accounts with privacy agreements. I install it in Linux. Now I will check if I can replicate this behavior. I am not sure if it is a violation of their agreement or not if they do, but I don't like it.
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.
It also passes obvious "Xen emulated drive", and similar for all hardware interfaces.
Passes CPUID.
Can't stop any of this with Qubes/Xen. But is trivial with Proxmox/KVM.
Honestly, I wish there was a Qubes/KVM variant. It would fix every complaint, and enable running potentially malicious software (MS windows) and lie to it regarding hardware interfaces.
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.
You make a very compelling argument. I've been thinking of at least trying it out before, but have been leaning towards it more and more over the years. A couple of questions though, if I could bother you with them?
How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?
And how programmable is the configuration of Qubes? I like the idea of NixOS for example, but given how comparatively little activity there is in the actual nix rather than the packages, and across so few developers, I worry what would happen if someone got hit by a bus or something. But I still like programmatically configuring computers over manual monkey patches, because I have the memory of a gold fish. :p
> How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?
I've used RDP w/ remmina and found the performance somewhat poor but usable-- I think it does too much video writes, so it's more like playing a video I expect Moonlight+Sunshine would be equal or worse. Xpra seems to work better than RDP for me. I didn't try to optimize the RDP since I tried xpra and it was better. (I use it to control remote GUI amateur radio software like WSJTX)
There are workarounds I didn't mention for video performance, e.g. handing direct hardware access to a GPU to a specific VM. But this obviously has security consequences and I don't have much experience with it.
Qubes itself is very thin. The most popular template vms (that you actually run apps in) are Fedora and Debian. The qubes system vms run on Fedora. So I think on the VM OSes themselves there is no maintenance concern-- so for example, you're not dependent on the qubes project for packaging software generally. (Though you do use qubes produced templates of the OS installs-- as they have some configuration to handle the overlay filesystems, clipboard, file transfer, networking, etc).
There is also work that people are doing to make NixOS a first class app vm image and even people working on being able to use it for dom0.
The qubes maintained stuff is dom0 and the glue that handles stuff like copying between VMs, wiring up networking to VMs, etc. Most of it is python. I've found relatively little need to mess with that stuff. Its configured via text files that are processed via (mostly) python scripts. Beyond the active developers there is a user community that has a lot of experience doing fancy stuff with the infrastructure, like adding support for ephemeral VMs that exist only in ram (for anti-forensics). I think that speaks positively to the maintainability of the system.
Ultimately because qubes is a system of VMs based on commodity OS migrating OUT shouldn't be fundamentally hard.
FWIW, I migrated in to qubes (from Fedora) by making an app VM for my existing laptop, copying the home into it. Then initially running everything in that one VM. It's not a good way to use Qubes, but it had me full on it in a couple hours with no loss of capability. From there it was easy to start moving things into other VMs until I no longer used the original.
> But using a multipurpose computer without qubes is unsafe at any speed, worse than driving without a seatbelt.
Could you elaborate on the odds of death and permanent disability occurring through use of unsecured general purpose computers? Because if not using qubes has the same risk profile as not wearing seatbelts I might feel like taking some measures
hah. There are computing death and dismemberment risks-- but I wouldn't expect qubes to solve one. (I'm thinking of my friends CNC router with the windows controller where windows decided mandatory upgrade time is NOW during an operation and it left an axis unsafely in motion necessitating a dive for the e-stop).
The serious point in my quip is that I've been a driver for over 30 years and yet to have a seatbelt protect me. I've been hit with computer attacks that qubes has limited. Might be kinda tricky to kill me from compromising my computer, at least today. Who knows about the computer.
Srsly, all those neck beards who over simplify the problem with a flippant "don't use zoom", as if everyone has the luxury to skip every job interview and employer meeting that absolutely requires Zoom. I wish I could live in their world where every problem is solved by simply avoiding that problem.
Zoom isn't just a technical problem. It's literally malware. The list of issues they've knowingly caused and sometimes even refused to fix is endless. They have made it clear they absolutely don't care about security in any way and they've built their entire business around that.
As I work in cyber security there's no way I'll install that shit on my personal PC. Yes I could spin up a VM but I don't want to. I could probably use it over the web but that's it.
So I'd refuse and that company's reply should inform me whether I'd want to work there in the first place. If they insist their security practices will be so lax that I will be just spending my time cleaning up everyone else's mess. In fact any employer using zoom in the first place is a huge red flag.
I currently work for a huge multinational and they have the zoom client blocked through antimalware. Anyone wishing to use it with customers or suppliers must use the web version only.
This is a habit tech people fall into. "Amazon deleted my book" -> well just strip the DRM off it. "My ISP monitors me" -> well just use a VPN instead. "Ads make it hard to use the internet" -> well just use an ad blocker.
Ironically if more tech people just rawdogged the internet I think we would have more progress.
Just use a browser instead of some silly client, problem mostly solved. Use X11 or Wayland or whatever else you want, for God's sake. I don't remember any god ever claiming salvation lies in abandoning the most functional display server on the market so I'll just keep on using X11. If and when Wayland or some other alternative ever becomes as useful as X11 I might hop over but for now Wayland is a solution in search of a problem as far as I'm concerned.
It takes experience to learn why people call it the "bleeding edge". GPU acceleration is often broken in a lot of distros, and it is unkind to new users that have a panic attack dropping into a CLI shell.
LightDM at least works 99% of the time, being Cross-desktop one can select a Wayland session just fine (great when it is working), or fall back to a software compositor Cinnamon Desktop when things bork after an update. =3
Fine words, until the GPU driver goes sideways in Wayland. And... I like running multi-seat headless sessions on my local LAN hosts for several reasons. =3
My partial solution is to have the Android Zoom client on an idle tablet. Even though it is my office VOIP phone too, I power it off when I don't have meetings scheduled.
If someone tries to demand screen sharing, I ask one of my coworkers to drive, since they've joined from their laptop already.
I only launch the Linux Zoom client when I absolutely know I'm going to need to host a meeting and demonstrate software running on my end. I feel equally disgusted about Zoom and the corporate EDR agent. I basically feel like the most likely source of compromise of my laptop is these proprietary tools forced on me from above.
The thing that worries me is SSO for work. I wish there was a completely different identity for all the work-related apps and for my payroll/benefits portal. I.e. if they want to endanger my login that manages my work product, fine, but I don't appreciate them endangering my login that manages my own compensation, tax deductions and retirement transfers, and health insurance...
As an engineer I’d be impressed and would put you up to the top of the pile
Sadly I don’t run the company, and as a hiring manager that’s a great way to reduce my shortlist. We can’t have people like myself who ignore corporate policies.
If we are doing a survey of self hosted video conferencing services I would like to propose galene. Very easy to set up, I run it on obsd(an unsupported platform) and it just works.
Perhaps things have gotten better over time, but I did this 4 or 5 years ago and it was anything but trivial. I got it working, but it was a huge pain to set up.
The docker image build recipes should be easy to find these days.
Usually it is just local networking appliance rules that cause issues for some users. Likely a great learning experience for the uninitiated. Have a great day =3
Zoom also works on all browsers. Clearly you had a hot take, people corrected you, and now you're doubling down by suggesting, of all things, a Google product.
The "clipboard" as it is implemented in many (most?) operating systems today, only exists because it's a legacy idea that hasn't died. If it were freshly invented today, it would never get past even the most lenient privacy review.
Think about the pitch for the feature: "So, we're going to make this in the OS, where the user can highlight anything in any application, invoke a command, and then that thing (which could be a sensitive password, private personal information, or the codes to a nuclear weapon) will instantly become available for all applications on the system to read and do anything with. Uhh... NO THANKS!
Ideally, if an application wants to read from the clipboard, it should explicitly ask the user for permission, or the user should have to specify the exact app he's copy/pasting to. This reduces the clipboard's ease of use, but at least makes it NOT a truck sized privacy hole.
No. You're assuming that you don't have control of your own computer.
Think about the pitch for removing the feature, "So, we're going to make this in the OS, where visually disabled users cannot highlight anything in any application, can't move text between applications, cannot get the window title, cannot get the window tree, cannot have applications automate or know where other applications are, and basically they won't be able to use their computers. But everyting will be super private. Even the human using the computer won't be able to read it." This is what modern linux desktop computer is on waylands thanks to this toxic privacy meme. It literally just doesn't work for me.
Privacy needs the kind you're talking about simply don't exist on desktop computers where the human actually controls everything (as opposed to smartphone model where the user controls very little and applications are hostile and opaque). If you want to break accessibility and functioning of smartphones, fine, go for it. But leave desktop computers alone.
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.
I think the solution is to really give the user control over when something is pasted and into which application. So if you press ctrl-V, it shouldn't pass that on to an application that then gets to poll the clipboard, instead the OS or window manager should send the contents of the clipboard to the application the moment ctrl-V is hit.
I remember a friend installing Zoom on a Linux computer through their software manager. Later, they removed it and found that when they visited the page in the software manager for Zoom, it automatically tried to install Zoom without interaction from them (ie, my friend did not click Install, but viewed the page and a password prompt for installing the package appeared).
I'm not sure if this was behaviour that happened with the software manager on other packages, but was a concern for us.
That's "rude" but allowed; that capability is one of the reasons Wayland was developed (though their solution removed some capabilities people wanted with the result that the compositors now replicate the original flaw).
Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware. If you want a "sandbox" run that program as a separate unprivileged user or use bubblewrap.
> 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?
Unix systems were initially designed to be multi-user systems (as in multiple meatbags accessing a mainframe across terminals), in an era before it was common to indiscriminately download and run applications from the internet. Files required explicit opt-in to become executable. There were always attempts at mischief, but it was deemed sufficient to separate user account from each other and denying direct access to the hardware so an account compromise wouldn't escalate to the rest of the system.
Because of this heritage Android uses user accounts instead of namespaces a.k.a. containers (a much newer and less mature concept) to isolate apps from each other.
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.
There is no such thing as an "X11 clipboard" that something can be written to. As the poster goes on to allude, X11 has a concept of a "selection" (a primary and a secondary one).
It goes roughly like this: when you select a text in a window, the X client tells the X server "I have the selection now", when you paste in another window, the client behind the other window asks "who has the selection?" and requests the selection contents from the other client, the data is then forwarded through the server. The client that claimed ownership has to properly handle some associated requests/events for the whole thing to work.
The key point is, there is no central "clipboard" style repository like on Windows, the client that does the "copy" is responsible for the data, the client that wants to "paste" has to talk to it. If I try to copy/paste and quit the source program before the paste, the data is gone. That's why modern desktop environments usually come with a dedicated daemon that immediately reacts to selection ownership changes, grabs the data for itself and then claims the selection ownership to emulate the Windows style behavior.
If we play devils advocate, it's possible the Zoom client tries to do just that, not trusting whatever desktop environment. I don't use this software, so I'm going out on a limb here, but I'd guess that the "Zoom Desktop Client" is just another browser in disguise? It might be actually Chromium or whatever underneath that does this?
It's not chromium. But what's happening here is that even if you don't click paste, zoom is actively listening to clipboard events and consuming pastes.
Tbh, if they aren't harvesting clipbakrds data which is a weird thing to do and is unlikely, this doesn't really mean much. Anyways any X client can read.
I suspect it's something like: a bug report that said that I copied the link but when I opened zoom and pasted it it didn't it work. I.e, they probably closed the source application and thus the selection owner is gone, and the selection is gone too. This fixes that. I would test that maybe. See if paste after source app close works. Then again, if you use a ownership changing clipboard manager this shudnt be a problem.
Not the first time Zoom abuses privilege.
A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end.
They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f...
I always ask (1) why does an app require installation and (2) why would it require root?
There are valid answers for both, but realistically, all a videoconferencing app should need (apart from audio and video and maybe screen sharing) is to store a config file.
There's no legitimate use for it accessing privileged or private paths.
> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f...
On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.
could xhost(1) help here?
I think the only possibility that comes to mind is creating an ebpf module that sandboxes all filesystem calls and trampolines all ld_open calls.
But then you would have to provide massive amounts of patched/"safe" variants of all kinds of shared libraries which is unfeasible.
But I mean in the xorg use case it would be possible to just provide your own library that fakes the expected returns and sends fake data to the sandboxed applications.
I did a similar thing with barrier (though using LD_PRELOAD, see [1]) on my debian system to force a different behavior.
Source: Am kind of experimenting with ebpf a lot for that use case. C ABIs and SO files are a mess though. A real messy mess.
[1] https://github.com/cookiengineer/barrier-disable-dpms
Not really - it's not sufficiently fine-grained and, besides, you need it to connect to X to display anything.
There were various attempts to improve this situation in the early 2010s, typically using Xnest or Xephyr in conjunction with other sandboxing techniques. I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention.
The fact is that the X model was never designed with these threats in mind.
> I believe Qubes OS followed that approach but it was awkward, limited, had major performance problems, and yet never managed to fully prevent circumvention.
Not sure what you are talking about. Qubes offers reliable protection with decent performance, unless you work with graphics. See also: https://news.ycombinator.com/item?id=49678250
That doesn't change that programs doing this can be shady (or very useful).
but sandboxing would be quite useless
How so? If you can break out of a sandbox then by definition it is not a sandbox.
There are ways to force sandbox jail. For instance, giving processes only a partial view of the computer system. GoboLinux did this years ago via ViewFS (https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-... search for ViewFS). There are many other similar solutions, some probably better.
X itself is the problem here, not the process attached to
You need to sandbox X11 which requires giving up X11 capabilities just like Wayland did.
Out of interest why do you still use the app and not just use it in the browser? I feel much more secure having it in the browser sandbox and everything I care about works in the browser.
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've been using the web client for over a year and that hasn't been the case the whole time, gallery view is an option.
Well this was back in COVID, sometime fresh after the always-open-port news had surfaced. Can easily believe the experience has been improved since then.
I always turn off incoming video on teams. Waste of bandwidth and cpu, so I don’t see the loss there.
So the web is a better experience!
Unless you have to run the meeting.
Everything is a better experience unless you have to run the meeting! ^_^
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.
Last time I looked at their web client, it was indeed doing absurd things (I think it used TCP and web sockets to carry video instead of WebRTC and shipped a WASM video codec that obviously can’t be GPU/hardware accelerated).
Not sure if that’s malice (to nudge people towards using their invasive desktop app) or incompetence.
That explains a lot. I would guess incompetence.
Close it when you’re done with the meeting.
By that time, your battery may already be dead.
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.
The link is just smaller, and I think the text is now something to the effect of "Can't Download App" or similar.
Yes Apple even blocked their app because they refused to fix it. Eventually they did and unfortunately they were allowed again.
It wasn't really root as much as an open backdoor on a TCP port as far as I recall.
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)
Apple did block the app so the 'working with Apple' didn't exactly earn Zoom a lot of trust with them otherwise they wouldn't have done it. They'd have let Zoom fix it in an update. And just make that update mandatory. They were just looking out for their own customers in limiting the impact, but for them to pull this handbrake means they really saw this as a big risk.
'But Cisco did it too!' is just whataboutism. It was shown to be exploited (IIRC to open scam websites) which was a real backdoor and a legitimate security risk, not a potential one.
This is something that should never have happened in the first place. Even releasing something like this in the first place is really showing no concern for the security of customers at all. What it looks like to me is that zoom wanted to conquer the market by ease of use and was willing to sacrifice security to do it. The zoombombing thing was another example.
And yes Apple has an emergency brake for malware outbreaks. And they've only used that one for high profile apps once, for zoom. They didn't do that lightly, especially during the pandemic when people were depending on it.
Really I have no good words for the actions of zoom. And there have been more incidents.
I was involved in mitigating these screwups in my work, what we did was flag zoom as malware ourselves so it automatically got removed from every company machine. And block it from being installed by the user. This block is still in place.
Ps I'm sorry if I sound harsh but zoom has caused several security worries at work and we don't even use it.
> 'But Cisco did it too!' is just whataboutism.
A whataboutism that makes a legitimate point. It isn't reasonable to dismiss something just because a person makes a comparison. It's valid to consider that Apple might have been applying inconsistent standards and unfairly targeting Zoom for some reason.
I doubt they were being unfair but it is a bad practice to dismiss an argument because someone has the temerity to expect consistent standards. The threat of Apple arbitrarily removing apps based on unreliable reasoning is concerning.
Cisco's one wasn't shown to be exploited though. Even after the news about the zoom one. They must have done something different.
But my point is that this should never have made it into an enterprise level product, even if someone else did it.
> Ps I'm sorry if I sound harsh Actually, thanks, that did go a long way.
It's not whataboutism, I'm not trying to distract from the point, I'm saying there was _prior art_ in the industry where customers appeared to tolerate this.
There was another PM on the team who felt the same way I did and we basically both wagged our fingers and said "you should have asked people during install", but who cares, it was too late.
Zoom had, I will say, a very... Chinese culture around software security. If you're familiar, Chinese software is often much more interested in just getting the job done in a simple way, and security is... not the job? I've used a lot of Chinese software that just wants full admin everything so no one had to learn about permissions.
Zoom wasn't exactly run that way, but the pool they hired from had a lot of that mentality in it.
I thought Apple's tool was ridiculous though. It's like "oh, some trash blew into our yards from the neighbor's trashcan" so Apple replies "oh, don't worry, I destroyed it with my orbital ion cannon" and the tech community never stops to wonder if maybe it's a little strange that Apple has an orbital ion cannon and maybe we should ask some questions about the ion cannon.
Asked people what during install? From my perspective this should have never been designed this way. I understand if you're a PM, but those engineers should've known better, Chinese or not.
As for the ion cannon (signed and notarized apps) people do talk about this and question it. Apple's infamous walled garden. Europe is trying to fix this with the Digital Markets Act (DMA) and the USA is trying to fix this with the right to repair.
But you have to admit, in this instance with Zoom, it was used for a just purpose. Apple protected end-users against bad code from Zoom, which from your post, seemed complacent.
As an apple user, I am glad that Apple has an orbital ion cannon that blows up lazy and/or malicious things that could affect me.
> I thought Apple's tool was ridiculous though. It's like "oh, some trash blew into our yards from the neighbor's trashcan" so Apple replies "oh, don't worry, I destroyed it with my orbital ion cannon" and the tech community never stops to wonder if maybe it's a little strange that Apple has an orbital ion cannon and maybe we should ask some questions about the ion cannon.
Nah, that's very on brand with Apple. The Apple ecosystem is well-known to be a walled garden where they rule and are very stringent about separation to the outside and being in control. People who use Apple products know what they are getting into.
> 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)
Because that’s a documented feature (malware protection).
As a user, I generally like it, and in this case I’m fully aligned with their classification of Zoom’s behavior as a nuisance. A lot of malware developers justify their behavior as “just doing what their users want/need”.
> A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end.
> There's no legitimate use for it accessing privileged or private paths.
Well, that was the whole premise that made Zoom popular in the first place! It was a true one click install which made onboarding frictionless for non-technical users
Security wise, it's insane but user experience wise, it was unbeatable and is what solidified their position. It's ironic nowadays that all of those tricks have been stripped away, making it just as painful as any other platform to install on a fresh machine.
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.
It is caused by Qt. Qt 6.8.8 monitors the clipboard, and an official notice has been issued regarding this. https://qt-project.atlassian.net/browse/QTBUG-149610
I only use their Web client, given that there is hardly any use for it other than some Webminars that insist in using Zoom.
Old platform limitations do not remove an application’s duty to minimize collection and offer clear controls
Wow thanks for the link. I have zoom on my personal laptop which isnt ideal. I always wanted to run it sandboxed
Just run these things in your browser. Despite the dark design patterns that try to trick you into installing their desktop client, the web-based versions are fine.
not if you have to host meetings! the web versions are feature incomplete and don't support something as simple as screensharing with your camera overlayed in a corner (essential for recorded meetings).
the zoom linux client consistiently locks up my entire computer whenever i copy from the chat. ridiculous.
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.
it's a client feature because zoom is terrible. you composite camera and screen on your end so viewers see it on one screen, and the zoom cloud recorder records only one streaming source at a time. without third party integration i cant save my camera feed and screenshare at the same time in the web version. it's terrible.
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.
nope, because if anyone else talks the focus then shifts to them and nobody can see your screenshare. you have to instead use obs' popout preview and screenshare that specific window, which doesn't work if you dont have a second or third monitor due to always needing to be maximized.
Unrelated to Zoom, but
> I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam.
This sounds very useful. Is the tool available anywhere? xclip -loops doesn't seem to do the trick, or maybe it just doesn't work that way on Wayland.
Turns out, Wayland has wl-copy:
https://man.archlinux.org/man/wl-copy.1
(i was also interested :)
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.
I wish most Linux distributions had something like a standardized permission manager in which you enable the single policies apps are running with, similarly to what happens in Android (that has some Linux stuff under the hood).
How hard would it be to have something like this? And I can’t even imagine the difficulty of gathering together the whole community around this standard...
> How hard would it be to have something like this?
Very. Both because of the technical issues others in this thread mentioned, and because Android and iOS had the unutterably massive advantages of starting from zero pre-existing software and having a single controlling authority.
The controlling authority allowed them to avoid problems related to consensus or people working on other priorities. Starting from zero allowed them to not worry about existing software (the closest thing to a controlling authority that Linux has cares a lot about backwards compatibility).
Quite hard because on Linux there is no concept of "apps". There is a (very flimsy) separation between processes, but the strongest actual security boundaries are between kernel and user space as well as between users. Namespaces are explicitly not acknowledged as such, which limits the security guarantees that containers can provide.
Snaps and Flatpak are steps towards that goal, but there are many issues surrounding these technologies, and many apps require sweeping permissions to work well since they were not initially designed to be limited in that way.
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.
Sure flatpak have a static permission system too, even it is not recommended and xdg portals are the way of integrating with a host.
https://flathub.org/en/apps/com.github.tchx84.Flatseal
I don't get why a big company like Zoom, with presumably lots of users who are on Linux, only gives us a .rpm/.deb instead of a Snap/Flatpak. Seems like doing the minimum.
Snaps is a sure-fire way to only get used on Ubuntu. So that would be worse than distributing .rpm/.deb.
It's possible to distribute more than one format.........
It looks like you are searching for Qubes OS.
> similarly to what happens in Android
Do you wish to give this app access to _all_ your {files, photos, phone calls, messages} ? /s
What do we need permissions for, then ? Let MS-DOS come back.
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.
It'd be easy, just build it into systemd.
.../s
Jokes on you, systemd-appd is in planning stages right now.
systemd-clipboardd? What could be better!
Zoom is malware, has always been.
Par for the course when running a proprietary application. If doing that on Linux, can you imagine what it and others do under Windows ?
As people running Linux should know, you cannot trust proprietary applications.
I would rather have a nice popup on first attempt "this application is monitoring your clipboard, allow?", ideally with that process completely suspended while that prompt is up.
This should be behind a toggle driven by intent, rather than something allowed by default. Default stance on trust should be "don't". Open source has nothing to do with it, when a typo while installing with a package manager means you might accidentally install something else (a common attack vector).
Feeling good about using Zoom, when necessary, in a tab in ChromeOS. Zoom is "Not allowed to see your clipboard" in Chrome preferences.
I miss ordinary conference calling being the norm. I like having a desktop IP phone.
It’s a real shame that essentially all modern communication other than email runs over proprietary protocols.
We use a lot of sip with all manner of endpoints
Sure, in a way SIP is bigger than ever with NGNs, and there’s SIP use beyond that too, but actual interoperable SIP (as in, I can dial sip:name@example.com) is effectively not a thing anymore.
I don’t deal with corporate telephony but our sip accounts on the broadcast side have all manner of endpoints, including software and hardware from many different manufacturers. We land them on a pair of paired oracle sbcs which somehow (I’m not close to the details on this part) shares account detail and sessions between the two geographically resilient locations.
You just need the dns, account and password.
I do believe that vendor-interoperable SIP exists today, but I also know that I can't call >99.9..9% of the people in the world via SIP, and 100% of the ones I practically do call.
This is a very different story from e.g. email – even though most people I communicate with use either Gmail or some hosted Outlook service, I don't have to on my side (with some limitations around deliverability etc. lately).
I also miss proper chat systems over proprietary ones. Slack offers very little utility over IRC.
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...
with Wayland it's generally not any safer.
if you use Wayland's security context to prohibit privileged protocols such as arbitrary clipboard access then an application will either not be able to grab clipboard content until you focus on it or the attempt will be noticeable as it spawns a short lived window in an attempt to grab focus.
Apps generally need not get clipboard contents unless focused on right? Like this should be the default in my view and kinda disappointed it isn't for Wayland.
https://jitsi.org/
Jitsi doesn't integrate with meeting rooms and calendars to my knowledge?
With Zoom we can have a setup where I just hit "join meeting" on a tablet in the meeting room and it'll join the meeting and pretty much just work.
For most normal meetings, this is the way to go. However, meetings that have hundreds to thousands of participants (corporate all-hands, investor earnings calls, etc), I just don't think it scales well enough.
Jitsi is an excellent free and open source alternative.
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 found Clients / Customers don't care, I just send them a meetings link and they find themselves shocked in that it just works.
If they moan say it's Zoom but the corporate version.
Self-hosting my own Jitsi and it's faultless and the way to go.
Just send a meeting link and it works in any browser.
I'm pleasantly surprised at how often someone will use jitsi when the alternative is not communicating with me in such a fashion.
Can’t see enjoying my time on this Earth putting up with that sort of burnout.
University of California has licensed zoom accounts with privacy agreements. I install it in Linux. Now I will check if I can replicate this behavior. I am not sure if it is a violation of their agreement or not if they do, but I don't like it.
Qubes OS saved me, once again. On it, Zoom only has the access to an empty VM and no access to the clipboard.
What's it like using Qubes? How much friction? I wish I could use some Nix-flavored variant of the sandboxing.
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.
Doesn't that preclude paravirtualization drivers? Seems like a major tradeoff for daily driver desktop stuff.
Xen prevents modifying ACPI data.
It also passes obvious "Xen emulated drive", and similar for all hardware interfaces.
Passes CPUID.
Can't stop any of this with Qubes/Xen. But is trivial with Proxmox/KVM.
Honestly, I wish there was a Qubes/KVM variant. It would fix every complaint, and enable running potentially malicious software (MS windows) and lie to it regarding hardware interfaces.
> Honestly, I wish there was a Qubes/KVM variant.
Relayed Issue: https://github.com/QubesOS/qubes-issues/issues/7051
Related Issue with discussion: https://github.com/QubesOS/qubes-issues/issues/1142
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.
You make a very compelling argument. I've been thinking of at least trying it out before, but have been leaning towards it more and more over the years. A couple of questions though, if I could bother you with them?
How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?
And how programmable is the configuration of Qubes? I like the idea of NixOS for example, but given how comparatively little activity there is in the actual nix rather than the packages, and across so few developers, I worry what would happen if someone got hit by a bus or something. But I still like programmatically configuring computers over manual monkey patches, because I have the memory of a gold fish. :p
> How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?
I've used RDP w/ remmina and found the performance somewhat poor but usable-- I think it does too much video writes, so it's more like playing a video I expect Moonlight+Sunshine would be equal or worse. Xpra seems to work better than RDP for me. I didn't try to optimize the RDP since I tried xpra and it was better. (I use it to control remote GUI amateur radio software like WSJTX)
There are workarounds I didn't mention for video performance, e.g. handing direct hardware access to a GPU to a specific VM. But this obviously has security consequences and I don't have much experience with it.
Qubes itself is very thin. The most popular template vms (that you actually run apps in) are Fedora and Debian. The qubes system vms run on Fedora. So I think on the VM OSes themselves there is no maintenance concern-- so for example, you're not dependent on the qubes project for packaging software generally. (Though you do use qubes produced templates of the OS installs-- as they have some configuration to handle the overlay filesystems, clipboard, file transfer, networking, etc).
There is also work that people are doing to make NixOS a first class app vm image and even people working on being able to use it for dom0.
The qubes maintained stuff is dom0 and the glue that handles stuff like copying between VMs, wiring up networking to VMs, etc. Most of it is python. I've found relatively little need to mess with that stuff. Its configured via text files that are processed via (mostly) python scripts. Beyond the active developers there is a user community that has a lot of experience doing fancy stuff with the infrastructure, like adding support for ephemeral VMs that exist only in ram (for anti-forensics). I think that speaks positively to the maintainability of the system.
Ultimately because qubes is a system of VMs based on commodity OS migrating OUT shouldn't be fundamentally hard.
FWIW, I migrated in to qubes (from Fedora) by making an app VM for my existing laptop, copying the home into it. Then initially running everything in that one VM. It's not a good way to use Qubes, but it had me full on it in a couple hours with no loss of capability. From there it was easy to start moving things into other VMs until I no longer used the original.
> But using a multipurpose computer without qubes is unsafe at any speed, worse than driving without a seatbelt.
Could you elaborate on the odds of death and permanent disability occurring through use of unsecured general purpose computers? Because if not using qubes has the same risk profile as not wearing seatbelts I might feel like taking some measures
hah. There are computing death and dismemberment risks-- but I wouldn't expect qubes to solve one. (I'm thinking of my friends CNC router with the windows controller where windows decided mandatory upgrade time is NOW during an operation and it left an axis unsafely in motion necessitating a dive for the e-stop).
The serious point in my quip is that I've been a driver for over 30 years and yet to have a seatbelt protect me. I've been hit with computer attacks that qubes has limited. Might be kinda tricky to kill me from compromising my computer, at least today. Who knows about the computer.
Just not using that piece of trash that is zoom would work very well too in this case
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
That's bad news. Don't use Zoom.
That's wildly impractical advice for many.
Just use Firefox, or Chromium if you must.
Spinning up a conference host for a small office is fairly trivial =3
https://jitsi.org/downloads/
Great, til I have a job interview and they use Zoom
Srsly, all those neck beards who over simplify the problem with a flippant "don't use zoom", as if everyone has the luxury to skip every job interview and employer meeting that absolutely requires Zoom. I wish I could live in their world where every problem is solved by simply avoiding that problem.
Zoom isn't just a technical problem. It's literally malware. The list of issues they've knowingly caused and sometimes even refused to fix is endless. They have made it clear they absolutely don't care about security in any way and they've built their entire business around that.
As I work in cyber security there's no way I'll install that shit on my personal PC. Yes I could spin up a VM but I don't want to. I could probably use it over the web but that's it.
So I'd refuse and that company's reply should inform me whether I'd want to work there in the first place. If they insist their security practices will be so lax that I will be just spending my time cleaning up everyone else's mess. In fact any employer using zoom in the first place is a huge red flag.
I currently work for a huge multinational and they have the zoom client blocked through antimalware. Anyone wishing to use it with customers or suppliers must use the web version only.
> I'd refuse and that company's reply should inform me whether I'd want to work there in the first place
This.
Develop sufficient leverage to be able to show basic respect the right way to do things - and yourself.
This is a habit tech people fall into. "Amazon deleted my book" -> well just strip the DRM off it. "My ISP monitors me" -> well just use a VPN instead. "Ads make it hard to use the internet" -> well just use an ad blocker.
Ironically if more tech people just rawdogged the internet I think we would have more progress.
Unfortunately, experience teaches people one can't affect political policy with gadgets, or deny human nature. =3
https://harmful.cat-v.org/people/basic-laws-of-human-stupidi...
Use a dedicated, otherwise empty account for job interviews.
Linux is multi-process, _multi-user_ since forever.
No need to leave a password manager, online banking, andwhatnot accessible in the background during an interview.
And yeah: stop. using. X11. For God's sake!
Just use a browser instead of some silly client, problem mostly solved. Use X11 or Wayland or whatever else you want, for God's sake. I don't remember any god ever claiming salvation lies in abandoning the most functional display server on the market so I'll just keep on using X11. If and when Wayland or some other alternative ever becomes as useful as X11 I might hop over but for now Wayland is a solution in search of a problem as far as I'm concerned.
It takes experience to learn why people call it the "bleeding edge". GPU acceleration is often broken in a lot of distros, and it is unkind to new users that have a panic attack dropping into a CLI shell.
LightDM at least works 99% of the time, being Cross-desktop one can select a Wayland session just fine (great when it is working), or fall back to a software compositor Cinnamon Desktop when things bork after an update. =3
Wayland doesn't work stable in kde on my OS yet so I have no choice but to use X11.
However software just shouldn't be trash. No need to blame the display layer for this.
>And yeah: stop. using. X11.
Fine words, until the GPU driver goes sideways in Wayland. And... I like running multi-seat headless sessions on my local LAN hosts for several reasons. =3
> And yeah: stop. using. X11. For God's sake!
Why should I stop using software that is superior to the alternatives?
It isn't though. For example, the very article we are discussing.
Last time I looked they had broken copy/paste behaviour which dates back decades
If said copy paste behavior allows any app to snoop on any other apps' clipboard content without control, then it's been broken for decades.
My partial solution is to have the Android Zoom client on an idle tablet. Even though it is my office VOIP phone too, I power it off when I don't have meetings scheduled.
If someone tries to demand screen sharing, I ask one of my coworkers to drive, since they've joined from their laptop already.
I only launch the Linux Zoom client when I absolutely know I'm going to need to host a meeting and demonstrate software running on my end. I feel equally disgusted about Zoom and the corporate EDR agent. I basically feel like the most likely source of compromise of my laptop is these proprietary tools forced on me from above.
The thing that worries me is SSO for work. I wish there was a completely different identity for all the work-related apps and for my payroll/benefits portal. I.e. if they want to endanger my login that manages my work product, fine, but I don't appreciate them endangering my login that manages my own compensation, tax deductions and retirement transfers, and health insurance...
so? avoid it where you can
Spin up your own instance and ask them to join!
Great idea, if you want to stay unemployed.
How many corpo HR/recruiter types you met that will gladly bypass company policy and switch to the tools demanded by the candidate?
As an engineer I’d be impressed and would put you up to the top of the pile
Sadly I don’t run the company, and as a hiring manager that’s a great way to reduce my shortlist. We can’t have people like myself who ignore corporate policies.
If we are doing a survey of self hosted video conferencing services I would like to propose galene. Very easy to set up, I run it on obsd(an unsupported platform) and it just works.
https://galene.org/
Very nice option, as getting WebRTC built on pi/aarch64 with v4l camera hardware codec support was a slog through mud a few years back. =3
Perhaps things have gotten better over time, but I did this 4 or 5 years ago and it was anything but trivial. I got it working, but it was a huge pain to set up.
The docker image build recipes should be easy to find these days.
Usually it is just local networking appliance rules that cause issues for some users. Likely a great learning experience for the uninitiated. Have a great day =3
Ah yes Jitsi! I have been invited to meet on Jitsi 0 times.
https://meet.jit.si/humanphilosophersdisplaceround
first time for everything
Or just use Google Meet on all browsers, which is more practical to use than Zoom.
Zero software to install.
Zoom also works on all browsers. Clearly you had a hot take, people corrected you, and now you're doubling down by suggesting, of all things, a Google product.
To be fair, you have to wrangle it into submission by having the app launch fail.
It's what we use at work and I'm sure it passed a security audit. How ironic.
That's very telling about the quality of the security audit.
Still better than Teams though.
The "clipboard" as it is implemented in many (most?) operating systems today, only exists because it's a legacy idea that hasn't died. If it were freshly invented today, it would never get past even the most lenient privacy review.
Think about the pitch for the feature: "So, we're going to make this in the OS, where the user can highlight anything in any application, invoke a command, and then that thing (which could be a sensitive password, private personal information, or the codes to a nuclear weapon) will instantly become available for all applications on the system to read and do anything with. Uhh... NO THANKS!
Ideally, if an application wants to read from the clipboard, it should explicitly ask the user for permission, or the user should have to specify the exact app he's copy/pasting to. This reduces the clipboard's ease of use, but at least makes it NOT a truck sized privacy hole.
No. You're assuming that you don't have control of your own computer.
Think about the pitch for removing the feature, "So, we're going to make this in the OS, where visually disabled users cannot highlight anything in any application, can't move text between applications, cannot get the window title, cannot get the window tree, cannot have applications automate or know where other applications are, and basically they won't be able to use their computers. But everyting will be super private. Even the human using the computer won't be able to read it." This is what modern linux desktop computer is on waylands thanks to this toxic privacy meme. It literally just doesn't work for me.
Privacy needs the kind you're talking about simply don't exist on desktop computers where the human actually controls everything (as opposed to smartphone model where the user controls very little and applications are hostile and opaque). If you want to break accessibility and functioning of smartphones, fine, go for it. But leave desktop computers alone.
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.
I think the solution is to really give the user control over when something is pasted and into which application. So if you press ctrl-V, it shouldn't pass that on to an application that then gets to poll the clipboard, instead the OS or window manager should send the contents of the clipboard to the application the moment ctrl-V is hit.
Why I always shutdown the zoom process as soon as meetings end.
I remember a friend installing Zoom on a Linux computer through their software manager. Later, they removed it and found that when they visited the page in the software manager for Zoom, it automatically tried to install Zoom without interaction from them (ie, my friend did not click Install, but viewed the page and a password prompt for installing the package appeared).
I'm not sure if this was behaviour that happened with the software manager on other packages, but was a concern for us.
Isn’t this one of the reasons Wayland is often recommended? Forgive me if I’m getting confused on this point.
Reason 1492835 to use Qubes OS.
Also reason 35892384242892 to not use proprietary software, especially proprietary software with network access.
I mean I agree with you, but the real world just wants to get work done.
Outsource trust more carefully.
That's so sad. These companies try to ruin Linux by spying on the user here.
It's not about Linux.
That's "rude" but allowed; that capability is one of the reasons Wayland was developed (though their solution removed some capabilities people wanted with the result that the compositors now replicate the original flaw).
I'm not surprised by news like this anymore. When will Linux distributions properly sandbox our applications?
Our phones have had a better permission system for years.
Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware. If you want a "sandbox" run that program as a separate unprivileged user or use bubblewrap.
> 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?
Unix systems were initially designed to be multi-user systems (as in multiple meatbags accessing a mainframe across terminals), in an era before it was common to indiscriminately download and run applications from the internet. Files required explicit opt-in to become executable. There were always attempts at mischief, but it was deemed sufficient to separate user account from each other and denying direct access to the hardware so an account compromise wouldn't escalate to the rest of the system.
Because of this heritage Android uses user accounts instead of namespaces a.k.a. containers (a much newer and less mature concept) to isolate apps from each other.
Android allows apps to read from the clipboard at will, though it does show a toast. GrapheneOS, I believe, asks for permission first.
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.
[flagged]
[flagged]
[dead]
[dead]
[dead]
[flagged]
There is no such thing as an "X11 clipboard" that something can be written to. As the poster goes on to allude, X11 has a concept of a "selection" (a primary and a secondary one).
It goes roughly like this: when you select a text in a window, the X client tells the X server "I have the selection now", when you paste in another window, the client behind the other window asks "who has the selection?" and requests the selection contents from the other client, the data is then forwarded through the server. The client that claimed ownership has to properly handle some associated requests/events for the whole thing to work.
The key point is, there is no central "clipboard" style repository like on Windows, the client that does the "copy" is responsible for the data, the client that wants to "paste" has to talk to it. If I try to copy/paste and quit the source program before the paste, the data is gone. That's why modern desktop environments usually come with a dedicated daemon that immediately reacts to selection ownership changes, grabs the data for itself and then claims the selection ownership to emulate the Windows style behavior.
If we play devils advocate, it's possible the Zoom client tries to do just that, not trusting whatever desktop environment. I don't use this software, so I'm going out on a limb here, but I'd guess that the "Zoom Desktop Client" is just another browser in disguise? It might be actually Chromium or whatever underneath that does this?
It's not chromium. But what's happening here is that even if you don't click paste, zoom is actively listening to clipboard events and consuming pastes.
Tbh, if they aren't harvesting clipbakrds data which is a weird thing to do and is unlikely, this doesn't really mean much. Anyways any X client can read.
I suspect it's something like: a bug report that said that I copied the link but when I opened zoom and pasted it it didn't it work. I.e, they probably closed the source application and thus the selection owner is gone, and the selection is gone too. This fixes that. I would test that maybe. See if paste after source app close works. Then again, if you use a ownership changing clipboard manager this shudnt be a problem.