This is a feature, not a bug, it is how you can compose an environment out of reusable components that are meant to do one thing by themselves. Tools like xbindkeys and xdotool work using this feature and the composability of X is how you can use the file manager from KDE with standalone window manager like i3 and a separate compositor (or no compositor). X is highly composable, even if many applications ignore that feature. If you know what you are doing you get a lot of power and flexibility with X, way more than any other window system (including Windows).

Proper/secure composability is designed not by exposing all internals, but by explicit APIs. For example, UNIX file descriptions and using them as stdin/stdout/stderr is a properly exposed API for reusable components, while the ability to plug into any function in the binary would not be.

X11, i.e. some of its implementations, don't expose all internals, and clients don't just plug into any function in the binary. The X11 protocol and some of its extensions clearly define how clients can communicate with each other or the server.

Wayland on the other hand does not. How and if clients can communicate with each other is considered out of the scope of the Wayland protocol, except a few exceptions (e.g. copy/paste) so it's up to the Wayland compositor. That's why there are already multiple different "APIs" to do screenshots on Wayland compositors, some more powerful some less, and not a single one is implemented by all major compositors - basically fragmentation hell. That's also why stuff like color pickers still don't work without tedious hacks (e.g. misusing some of the screenshot APIs).

It doesn't expose its internals, the equivalent to UNIX file descriptors in X is the XID (Window, Pixmap, etc). Much like you can give any process any file descriptor to work with, you can also give any process any XID to work with. And like you can combine the text output of processes by redirecting their stdio, you can combine the graphical output by combining their elements (it isn't exactly equivalent of course, partly due to increased complexity inherent in GUI applications but also due to little standardization and tools, but still several of elements in an X desktop - outside GNOME and KDE that implement their own functionality which ignore X - work like that).

> any app can subscribe to events of any other app

Yes, that's a feature I have used many times in the past. If you want to sandbox an app, run it through a nested X server.

Indeed.

And for Windows, more than once I wrote stuff that captures or injects keystrokes globally. Being able to do this is a feature that lets you solve problems by making things more interoperable.

AFAIK you can't get any hardware acceleration that way.

Depends on the X server, i think Xnest uses just a dumb framebuffer but i think Xephyr can use acceleration just fine.

Wow, i have a lot to learn.... Do you know if these sort of things are still possible on wayland ? What about a Flatpak app on Wayland, does that help ? Because I think I've read somewhere that Flatpak apps on X11 was this way, implying that with Wayland it wasn't. I wish i had more time to dive into this sort of stuff...

Flatpak does aggressively isolate apps from the OS though: http://docs.flatpak.org/en/latest/working-with-the-sandbox.h...

Wayland indeed closes a lot of these huge holes. It's one of the core reasons for its introduction.

Flatpak has no X11 sandbox. Others, like Firejail, have attempted to create X11 sandboxes, but they've had holes (last I tested they had the X RECORD extension enabled, which has no use except being a keylogger), or broke valid applications / accessibility tools.

No, Wayland doesn't close any of those huge holes. That's like saying: We removed all the windows to your house, you should now be safe from people spying on you or stealing your stuff.

Wayland doesn't grant Wayland clients permission to those resources, but without further sandboxing and using technologies like Linux namespaces, AppArmor, SELinux, ... that's completely useless in itself. Wayland only makes it harder/impossible for trustworthy applications to do their job, while malicious applications just take one of the many other routes to get what they want.

> Wayland doesn't grant Wayland clients permission to those resources, but without further sandboxing and using technologies like Linux namespaces, AppArmor, SELinux, ... that's completely useless in itself. Wayland only makes it harder/impossible for trustworthy applications to do their job, while malicious applications just take one of the many other routes to get what they want.

What you described is exactly the paper of Flatpak, I think it even used SELinux for it. AFAIK, Flatpak with Wayland is a good way to sandbox apps on Linux.

A good way to sandbox applications is where you get a secure system without much effort but you still can grant applications certain privileges, because as a matter of fact some applications just need access to sensitive data to do their work. With Wayland that's basically impossible, since there's no standardized way to grant your hotkey manager access to the global input, or your color picker permission to read the color of an arbitrary pixel on the screen, ... It's security by not doing anything.

With X11 on the other hand I can sandbox X11 clients I don't trust, thereby limiting them in what they can do, but other clients I do trust have the ability to do all sorts of great things so I can do my work efficiently. While not perfect, not even close, it's certainly better than not being allowed to do anything.