I am neither fond of Xorg nor Wayland. I have used both and I see shortcomings of both.
Xorg is Overly Bloated/Done without giving much importance to security.
On the other hand, Wayland is technically superior , might be more secure than Xorg. But, it's feature parity doesn't match with that of Xorg.
Now,i don't think those features must be pushed into Wayland itself. i don't know but something desktop oriented Wayland implementation with those missing pieces filled would be good idea.
But, will security suffer? Maybe. For example, Wayland is said to be secure because window can't see other windows. But, necessity arose due to requirement of Screen Recording so some API was created to access The Screen. So, didn't it make that security claim irrelevant because each window can access the screen? i think it's still not thought out properly.
Once upon a time, I had to write a system where the rendering architecture was broken up into an engine that ran in a separate service, and the pixels were then dumped to windows owned by client programs. Long story, it seemed like a good idea at the time.
Mac OS X had a very secure graphics architecture where no program could emit pixels into the window content of another program. As a result? We could barely support OSX. We ended up having to do rendering to pixel buffers and then using mmap through an invisible file shared between the service and client, then dumping the contents of the pixel buffer straight to screen using some code every client ran. Rendering from graphics card to RAM back to video buffer cost us half our frame rate.
On Windows? Client program passed its HWND to the service. Service bound an OpenGL target as a child of the client program's window.
Security is important, but in a graphics service, it creates a solid trade-off between what is possible and what is safe. That HWND trick can definitely be used to fake a login window and steal user passwords. But it also allows some programs to run on Windows that were technically impossible on Mac OSX without a complete rearchitecting.
(Clarification: I've gotten out of the game of writing Mac OSX software, but if I understand correctly that trick is possible under the modern architecture. It turns out Apple needed the ability for one program to write into another program's windows directly because they architected QuickTime as a service and performant video display required a similar trick to the one we were doing. So they added a mechanism for two processes to describe a shared rendering target to Quartz).
> So, didn't it make that security claim irrelevant because each window can access the screen?
No, because these APIs allow the user to audit the requests and allow or deny. You could have a default-allow policy and get back to the X security but most implementations ask you to confirm first.
It’s more of a future feature. Until we have most things sandboxed with SELinux there isn’t a whole lot of point adding a permissions dialog. But all of this work pays off in the future when Linux can match macOS in security.
Xorg is Overly Bloated/Done without giving much importance to security.
On the other hand, Wayland is technically superior , might be more secure than Xorg. But, it's feature parity doesn't match with that of Xorg.
Now,i don't think those features must be pushed into Wayland itself. i don't know but something desktop oriented Wayland implementation with those missing pieces filled would be good idea.
But, will security suffer? Maybe. For example, Wayland is said to be secure because window can't see other windows. But, necessity arose due to requirement of Screen Recording so some API was created to access The Screen. So, didn't it make that security claim irrelevant because each window can access the screen? i think it's still not thought out properly.