> how many people are running untrusted GUI apps in a sandbox on a desktop?

1. More and more every day - and that should be our goal. More sandboxed apps, not less. Otherwise, Linux on the desktop will never be as secure as a Mac (which has, objectively, the best desktop app permission systems available).

2. Xorg only does windows, with no sense of importance. What's the problem with that? For a long time, this meant that the Lock Screen was literally just a window, drawn on top of all your other windows. If anything crashed your Lock Screen, system was open for business. This has been heavily hacked and worked around, but it's still a potential threat. Some of the more "lightweight" distributions still use software that is vulnerable to this; because we've sure patched the hell out of that Lock Screen software to please not crash.

3. Keyloggers. More and more apps are using Electron - and shipping JavaScript and other code right to your device with a potentially obsolete browser engine. The last thing you want is some JavaScript shipped to your out-of-date Electron app that keylogs what you are doing on your entire desktop; simply because the developer misconfigured CORS or didn't use a pinned certificate or there was a middleman on your network or numerous other possibilities. On Xorg, that's completely theoretically possible. Combined with issue #2, where your Lock Screen is quite possibly just another window to be keylogged, and you start to see how things can escalate quickly.

4. Xorg is never just Xorg. Xorg, by itself, is almost unusable in 2023. You need extensions - over 30 of them built on top of Xorg, to result in a functional desktop. Sounds super secure. Even worse, Xorg has a mandate to never break userspace - so once an extension is shipped, it's there forever. As a result, many of these extensions aren't even used or tested, which is why Linux has, if I recall correctly, 4 Xorg extensions to handle a mouse with only one of them being used. There's also multiple abandoned joystick extensions. Again, sounds secure.

These are not the attributes, or traits, of a secure system that we should be proud of. It's embarrassing and the sign of hobbyist work.

There's also other issues at play:

1. Xorg is so obscenely complicated, and the code so bad, that the developers have openly remarked there are probably less than a dozen people who understand Xorg and can actually work on it. That doesn't sound like a very good long term plan.

2. Xorg is both the protocol and the implementation, which isn't how you want to do things. Normally, you want a standardized protocol; with multiple implementations of the protocol, so that the protocol can be easily adapted for the use case available. We did this with the internet, where HTTP is the protocol, and the various web browsers are the implementation. Imagine if Netscape was the protocol and the implementation combined. That sucks. With Wayland, Wayland is the protocol, but Mutter or KWin or others are the implementations. Some implementations are better than others, but that's OK. If you want to one day rewrite your compositor to take Wayland instructions and execute them in Rust, you "easily" can. On Xorg, you're reverse-engineering and mimicking behavior bug-for-bug the full stack downward.

3. There are upcoming technologies that may be exceedingly difficult, if not impossible, to build into Xorg. Like good 144hz support, or HDR. You might not care about them yet - but trying to shoehorn them into Xorg is a bridge too far.