Xorg's security (and X11 in general) is objectively terrible - this is not even a debatable question.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
- Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions.
- No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything.
- No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords.
- System events are broadcasted via dbus to any app wanting to listen to them.
More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after.
There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time.
> More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory...
I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?"
Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed.
Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution
Flatpak/Snap/etc., also can assist with a layer of local-app security here.
Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
Making server side decorations an important part of it. Oh, the irony.
Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
I'm confused where I'm likely to be suffering. If I start using Wayland tomorrow would I even notice? Apart from having to switch DEs, of course.
You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware.
Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager.
The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working.
Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X.
There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
Hopefully someone will come up with Wayland emulation layer for x11 then.
Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.