Hacker News Reader

Comment by microtonal | Hacker News Reader

Upsides: more secure (in X.org every client can read every other client's keystrokes, pointer position, and do screen grabs), generally smoother rendering, better support for mixed-DPI setups.

Current downsides: worse support for screen recording/sharing (e.g. not supported in Skype), a bug in the compositor (e.g. GNOME Mutter) can bring your whole session down, not-as-good NVIDIA support (also depending on the compositor).

I have been using Wayland for two years or so an wouldn't want to go back. I do miss wide screen sharing support, because I am working remotely and Skype is the primary means of communication.

View on HN

> a bug in the compositor (e.g. GNOME Mutter) can bring your whole session down,

True for Gnome, no issue for KDE. Their arguably better design decisions led them to proceed slower though.

> Upsides: more secure (in X.org every client can read every other client's keystrokes, pointer position, and do screen grabs)

What if i want this as a feature? Does wayland allow this per app?

The screen-grabbing app would have to interface with the compositor instead of the display server. For example, krfb is adding Wayland screen sharing support with KDE.

Is this better from a security standpoint? Does the compositor verify clients in a more secure fashion? Presumably screenshotting is still a thing on Wayland so this has to be a solved problem.

The idea is that the compositor can then pop up a dialog saying "App X wants to record your screen. Allow?"

It could also limit recording to certain windows, or heck even redraw the whole screen any way it wants, like pretending sensitive windows aren't there.

The point is apps can’t grab other apps input/output. If you run the app in an otherwise secure manner (eg execute in a perfect security chroot/container).

A malicious application on your host can still do anything at the executing privilege level (read .ssh, inject malware into .bashrc) but can’t sniff your gksudo password

Why would you assume it's a solved problem? Basically every compositor has to implement this feature.

Does this lead to a more fragmented application space? If each compostor required its own screen grabbing tool, and each DE has its own compostor?

Whilst backend implementations are going to be different per-compositor, they're exposed as freedesktop apis so tools shouldn't need to be adjusted for each one.

I respect what your saying, but I’ve seen that model tried and failed multiple times

Furthermore I kind of wonder if anybody bringing up this point has ever in their life seen or heard of a malicious X11 client ...

I know this is not how security works (a theoretical hole is often as bad as a practical one) but it's a bit like saying you should have antivirus software, to which I might say: where are the viruses?

If containerisation takes off and ends up being perfect security it’ll make sense. An example would be running Android on X, apps would be able to read / modify windows of other apps via The X socket.

Why would anyone suppose that containers on Linux which are designed to keep applications isolated enough not to interfere with each other ends up being perfectly secure when it's not really designed to be secure at all?

I’m not suggesting it’s sane particularly if your threat model is nation state level actors, but people use containers (chroot, docker, vms) as a security boundary all the time.

Neither chroot or docker is a worthwhile security boundary. People that act as if it is risk appearing incompetent when they get compromised.

I’d argue that anything but bare metal is not a good compromise, but I’m not balancing the books of a large company.

People care about docker escapes so they’re getting more difficult, at least.

Edit: Plus, I’d rather $app_i_dont_fully_trust be sitting in a container rather than on my host. And no, not running apps i don’t fully trust is not something which is at all viable for me.

Haven't switched yet. Under Wayland, can users which are not owning the session display an app on the Wayland session/server? (e.g. under X I can do something like "xhost +" and then have any user display an app on the X server). I'm not asking about the security implications of doing that under X (as you already mentioned, X is less secure and an app can read another app's screen content etc.): just if it's doable or not under Wayland?

Whoever has access to your wayland socket can display applications. Root already has access to all the things so for running apps as root (e.g. wireshark) you just need to configure sudo/doas/whatever-you-use to keep XDG_RUNTIME_DIR and WAYLAND_DISPLAY. e.g. in my doas.conf:

permit setenv { HOME LC_ALL TERM XDG_RUNTIME_DIR WAYLAND_DISPLAY } greg as root

and I can just run 'doas wireshark'.

What about running a GUI from a local or remote ssh session?

Eg previously I would execute DISPLAY=:0 mplayer foo.avi to play remotely or ssh -X root@foo xcalc to display xcalc on my local monitor but execute on rhost

To some extent you're looking for Waypipe, which aims to bring the X-style network transparency model to Wayland apps: https://gitlab.freedesktop.org/mstoeckl/waypipe

X forwarding works just fine with Xwayland.

Very interesting, thanks a lot. I'll definitely give Wayland a try soon!

I've found wayland still has strange input, if there's a lot of CPU usage going on (something compiling or whatever) then the mouse and keyboard input will 'lag' and get stuck, plus it feels worse in games to me but the benefits seem really good, I hope wayland can keep improving so I can switch without it feeling worse for me

Did you try to use WebRTC PipeWire for screen sharing?

Yes, it works with some applications, like Jitsi. No luck with Skype so far.

Isn’t modern Skype using WebRTC that would be supported at least in beta with xdg-desktop-portal?

Reply on news.ycombinator.com