Show HN: X11 tool to share a screen area in any video meeting

Is it much more difficult under Wayland?

Wayland intentionally makes this more difficult, because one of the security goals of the project is that (by default) Wayland clients shouldn't have visibility into other clients' window contents/events/etc.

Of course, it still needs to be possible under Wayland, because there are plenty of legitimate use-cases (screenshots, screen sharing, video capture, etc.), but it was a non-goal to make it as simple as X.

Wayland merged the image-capture-source and image-copy-capture protocol extensions earlier this year: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture

> Wayland intentionally makes this more difficult,

some men just want to watch the world burn

And Wayland keeps their apps from spying on the rest of my screen!

I never understood the rationale for Wayland's "security"...

All the programs that I use (ls, rm, vim, ...) can "spy" to each other, and have unrestricted read/write access to all the bytes in my home directory. That's the whole point: I run these programs to control said bytes. What's so special about the pixels of my screen that the programs that manipulate them need to be protected from each other? If anything, the pixels in my screen seem less critical to security that the bytes in my disk. But Wayland insists in making that difficult, for incomprehensible reasons. Those are my pixels and I want to do what I decide, not what Wayland lets me to. I control my programs, not the other way round. If I decide that this program reads one pixel on my whole screen, or the global mouse position, or whatever, I see no point in forbidding me to do it.

Of course, if I want to run some rogue program whose author I don't trust, I will do so inside a limited container. But this has nothing to do with graphical applications. I wouldn't like the rogue program to read my homedir either.

Where does this paranoia come from? The kind of attacks cited by Wayland advocates are all theoretically possible but virtually unheard of in practice. In any time in the past thirty years, has there ever been a case of a rogue program in the Debian repos that maliciously spies on the user by exploiting the open and trusting nature of X11? Even if you expand the scope of consideration to applications like browsers getting pwnd by RCE zero days and then doing this, how often does this actually happen? Maybe this degree of paranoia, fear of technically possible but actually extremely rare scenarios, makes sense for targeted individuals like reporters and whistleblowers operating in totalitarian countries, but for anybody else it seems insane. It's like having deadbolts on your bedroom door because you're afraid of somebody trying to kidnap you in the middle of the night, that extra security against such an unlikely threat isn't worth the inconvenience. Except actually, getting kidnapped in the middle of the night is probably a more common occurrence than getting pwned through X11 programs from your distro repos.

The rationale is that you can have a GUI in one of those limited containers and not spy on all your other windows.

I don't run "apps" on my PC. I run programs from a trusted source repository. I expect those programs to not be hindered in their attempts to serve me.

You already can with X11, for example running your rogue graphical program inside a graphical virtual machine. The vm gui will filter-out the events that happen outside the window and the rogue program will think it's running alone.

It's nice that wayland makes such containerization much lighter, at least concerning the GUI (you still need to hide your filesystem, network, etc if you want to run rogue programs under wayland). But I don't see the point in enforcing it for each and every one of your programs. It's extremely unergonomic.

I think the general direction where Wayland, Flatpak and other similar sandbox frameworks are going is that of users running proprietary, untrusted and more or less user-hostile apps on the desktop, just like on tables and smartphones.