X has security issues. For example, an application that has access to your display can do stuff with other applications.
For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-securit...
For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-securit...
Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data!
Regardless of x11/wayland, the application "vim" can read (and change!) all files in my home dir. Do you also consider that a security issue?
If you want to run some weird application that you don't trust, you should run it inside a container. But that has nothing to do with display systems.
The attack surface of Vim is admittedly small, but the browser is a much bigger target. I want my browser to download files, upload files that I provide, and various other things on an allow list, but not more.
IDEs, the tools invoked by them, and their build artifacts should have access to the project assets and not much more.
There are certainly applications that require more privileges, but I'm sure we can come up with ways to restrict them as well. The problem is that it's quite late to retrofit it onto desktop Linux.
Containers are not designed to be security boundaries. They isolate their contents from the host system, but not primarily because of security. They can be used for security, but certainly not with default settings.
So you'd prefer your graphics system to act as a security boundary? Seems very weird to me. Containers are clearly the right tool for this job, for they can run as well for non-graphical programs.
On X, it is possible for an exploit in a browser to gain root if you have an application opened as root.
Although such exploit would be extremely difficult to pull off, state actors will do anything for specific targets.
That's either not a problem for me because I am of no interest to them. Or it is a problem that no amount of fiddling with software can mitigate because they can just beat me until I give up.
It's been a long time since I daily drove Windows, but I'd assume it's still the same situation over there.
I don't care. Sandboxing is annoying, cumbersome. I'm not going to create a container for every single app I run, so Wayland brings zero additional security.
If once in a honeymoon I need to run shady software I use a VM.
You don't have to create a container by yourself, a good desktop will do it for you. One such solution is Flatpak. Many applications don't work that great with Flatpak yet and require quite sweeping additional privileges, but we will probably see improvements over time.
There's nothing wrong with users deciding to just have a common folder with all their data, but some applications are of more sensitive nature than others and it should be possible to secure them better. For example password managers or terminals.
Why do you think webbrowsers go through great lengths to isolate different tabs from each other?
If you are doing X11 forwarding via SSH it defaults to a more restricted configuration that only allows a more restricted access to the server (no direct sniffing of the input devices for instance).
Do you expect that random webpages are ableto steal all data from all applications you run, and all files you have? Including passwords etc.
In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.
I think the Qubes approach is the only one worth considering if one deeply cares about security.
Are there any writeups that make a case for how Wayland could be used to implement robust GUI isolation?
A few years ago I brought up X on a Y2 display. Ended up implementing RGB888->Y2 blue noise dithering in the driver when I realized how much work native Y2 would be.
The only software that had problems were various installers for some professional programs, which were written in Java and which crashed immediately on 10-bit color displays.
However that was a Java problem, not an X11 problem, because the same installers also crashed on Windows when the display was configured in the 10-bit color mode.
Of course the color management in X is not good, but I have not heard yet about significant improvements in Wayland.
In my opinion, the only right way to handle color would have been for all user applications to work only in a linear wide gamut FP16 RGB color space, like Rec. 2020. Only the display driver should be aware of the characteristics of the display, like color primaries, gamma, HDR, color resolution or pixel encoding, which should be used for an output conversion in the GPU.
AFAIK, Wayland has also missed the opportunity to make such radical changes.
I forgot about 10bit. I should have said indexed-mode or non-true-color. I meant anything below RGB888.
Linear for processing would be nice where that conversion can be done efficiently, and where the display driver can make a passable representation.
The system I worked on only had black, light grey, dark grey, and white. What was nice about X was that the driver could express its limitations to clients, so that the client could make smart rendering decisions and handle dithering vs not dithering appropriately, rather than doing it at the display driver layer.
Looks like we're gonna have to devise a whole 'nother display protocol to accommodate larger pixel sizes... unless...
On Windows, one app can send events to another window too.
This is why Wayland adoption is slow.
And Wayland is just a protocol, I would rather trust some old X11 code that was shared by entire Desktop Linux then GNOME devs code, this is my personal opinion and I will not bring forward sourced/evidence why I do not trust GNOME devs and designers.