Exposing the Wayland lie (2018) | Hacker News Reader

Exposing the Wayland lie (2018)

catfox.life

116 pointsubercow13124 comments

I am the maintainer of the most influential library in the Wayland ecosystem, forming the foundation of a strong majority of Wayland compositors, and the author of a popular Wayland compositor on top of this still. Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. Here is my appeal to the author, with some edits for the sake of general audiences:

>I'd like to ask you to update this with a retraction at the top. I'm not sure if you recall when we spoke about this on IRC a few months ago, but each of these points is entirely false, and the article is a dishonest smear on Wayland (though I assume you only had the best of intentions). To recap:

>1 - recording events from libinput only works if you're root, and if you're root, you can do whatever you want. This is hardly a valid criticism of Wayland. LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. None of this is a mark against Wayland - it's only one part of a secure system, and the other parts are mandatory.

>2 - Wayland is a protocol, not its implementation. And many implementations are widely supported by older hardware. wlroots, which is the dominant Wayland ecosystem with over 75% of all compositors using it for their rendering, requires only GLESv2, which is the most broadly supported OpenGL standard.

>3 - The headline doesn't match the body, but both are wrong. The design of Wayland and its implementations is indeed much simpler than X11/xorg-server. As for the use-cases brought up in the body of this point, the caracatures of Wayland developers are rude and incorrect. For network transparency, it wouldn't be difficult but no one who cares has stepped up to do the work. Multiple clipboards are now supported. Many of the pieces of remote desktop are in place, and again someone who cares needs to step up to implement the rest and tie it together. We are ready and waiting to support anyone who wants to step up to complete this work.

>4 - A bug in xorg-server will similarly bring down your X session. Driver bugs affect both. Bugs are addressed when they're found, what more do you want from us? Regardless, restart protocols are in the research phase and your comments about the security holes implicated are blatant speculation.

>Support whatever you wish in your distro, but please don't publish dishonest articles.

> Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood.

That doesn't sound reasonable.

> LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks.

This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)?

> >4 - A bug in xorg-server will similarly bring down your X session.

A Xorg server needs to implement:

- the display server

A Wayland compositor needs to implement:

- the display server

- the window manager

- the compositor

- the hotkey daemon

- the screenshotting tool

- everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions.

I'm not really sure what's XWayland's story security-wise, but from my limited understanding, it is a component that is not going away soon, and allows bypassing some limitations of Wayland's API in order to accommodate X11 clients.

>This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)?

It's not the Wayland compositor's responsibility to provide an entire security solution, just like it's not the deadbolt manufacturer's responsibility to install an alarm system and security cameras. This isn't a criticism of Wayland, at best it's a criticism of your Linux distro.

Flatpak does answer this question, but fwiw in the Sway camp we're still looking into lighter-weight solutions.

>A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions.

This is only partially true. wlroots implements screenshots the same way that xorg-server does: by providing an API for exporting pixels to clients. The actual screenshot tool is a standalone program which can crash without affecting the compositor. This design is virtually identical to X, except easier to secure. The same can be said of many of your other points.

Let's say every attack vector exposed by wayland involves user being root or somehow having sudo access or somehow being exempt in pam or somehow having special access to input devices or being promoted through an ssh config or being promoted through a vpn config.

That is still a huge attack vector considering that the userbase is desktop users and not companies with security teams.

If you expect Wayland to protect users who give arbitrary programs root access, I have nothing more to say to you.

I expect attack vectors to be equal or less than X. Also consider what I wrote instead of repeating the same mantra of full root access.

I don't quite understand. A rouge root user in X can just replace the /usr/bin/X binary with their own version which records the screen and logs user input or does whatever they want the next time the user restarts X, or better yet, install a kernel module of their own and have arbitrary code running in ring 0.

What exact attack vectors do you see in X which you don't see in Wayland, which actually makes a difference and isn't completely overshadowed by all the other things a root user can do?

Can you change /usr/bin/X if you are only given access to /dev ?

If you're running alone in a sandbox as root, you can just insert a kernel module which breaks you out of the sandbox.

>That is still a huge attack vector considering that the userbase is desktop users and not companies with security teams.

Because the default in Linux is for Desktop users to login as roots?

Where have you seen that?

Because after you use linux for a couple of years you become dangerously knowledgeable and apply workarounds to make things more convenient, such as allowing no password with sudo. Surprised I had to explain this, though.

If you leave your keys in your front door and get robbed, your insurance will laugh you out the window when you try to file a claim. Surprised I had to explain this, though.

Whether a particular theft is covered would depend on the specific language of your insurance contract. For example, a theft might be covered where leaving the keys in the door was a rare lapse in otherwise good security (reasonable), but not in the case where it was the the regular procedure (negligent). Coverage might also depend on how the specific contract language has been interpreted by courts in your jurisdiction in the past.

>Surprised I had to explain this, though.

I'm surprised you even think taking such shortcuts has any bearing to wether Wayland is secure.

People that "become dangerously knowledgeable and apply workarounds to make things more convenient, such as allowing no password with sudo" should not have much expectations for security.

The same way if you leave your front door open in a street level inner city apartment, don't be surprised to be robbed.

sudo or root is not the only way you can read someone's logs, which I tried to explain above, so the whole point is moot.

> Where have you seen that?

Puppy Linux actually does that[0].

[0]: http://puppylinux.org/wikka/Spot

Which looks like a "distro" somebody developed from their parents basement in their pajamas.

I'm sure there's some such distro doing all kinds of inane shit one can think of, but, like the fact that some people are cannibals, doesn't make canibalism an actual established practice in society.

That's irrelevant. If they don't, they should, and it's not Wayland's problem.

I generally agree with you, just wanted to note one thing: for some, GLES requirement is actually quite a big one. Getting proprietary PowerVR drivers to work on mainline kernels is a nightmare, for instance - and of course, if you don't want blobs, you can't even use that. There are plenty of devices out there that work pretty well with X11 and no GLES.

However, I believe KWin has a QPainter rendering backend available, so that's not something inherently tied to the Wayland protocol.

There's always llvmpipe [1] as a last resort. Do you think that a Wayland compositor plus llvmpipe is inherently more CPU intensive than Xorg without a compositor using fbdev?

[1]: https://www.mesa3d.org/llvmpipe.html

Yup, it definitely is. For some hardware it may not make a big difference, but for others it will be a deal breaker.

Also, when I checked recently, wlroots seemed to not use a shadow buffer with llvmpipe, which makes it even less performant than it could be. It should be easily fixable though.

In a comment last year, Sir_Cmpwn wrote:

> We don't just paste pixels on the screen, we composite them. This involves alpha blending, projecting the scene onto an orthographic output projection, and more.

What would we lose, in usability and not just eye candy, if the "compositor" did just paste pixels onto the screen? Woudl such a compositor be as usable without GL as Xorg is?

You lose any alpha blending and ability to retain the contents of window if the app responds slowly or stops responding at all. Some other features like hidpi scaling done by compositor would also be lost. Otherwise it seems like it might be doable (although I'm not 100% sure, Wayland protocol definitely wasn't designed with this in mind), but the implementation would be so different to the standard GLES mode that it should probably be just a separate project.

A perfectly usable GUI is possible without alpha blending, isn't it? If I'm not mistaken, Windows didn't have alpha blending until Windows 2000, and it was still a runaway success.

Alpha blending and retaining the contents of windows doesn't need a full-blown compositor...

Indeed, GL is not a Wayland requirement. The core protocol only requires the compositor to support wl_shm (shared memory). Some compositors have a software-only mode (e.g. Weston, and you mentioned KWin).

Came to the comments looking for your response. I've learned a lot about Wayland from your blog, and I really don't understand the hate and resistance that some people have for it.

1) The UNIX security model puts users all in the same security domain. It's a given that a process running as user X can do whatever it wants with another process running as user X. I agree there may be better security models possible and even desirable in 2019, but at the end of the day, those are new and different security models. Does Wayland target standard UNIX security models, or does it require a specific new security model?

1b) The only really secure sandbox in 2019 appears to be complete hardware isolation. With Xpra, I can do this, and have windows from all my different security domains mapped on the same rootless display. I don't see any way to do the same with Wayland? (In fact, Xpra is buggy enough that if Wayland has a way to do this, it might be a killer feature and convince me to switch!)

2) Even GLES doesn't work without 3D acceleration stuff. I'm currently using a Radeon 7950, but only with the stock fbdev driver due to unresolved kernel bugs using the radeon driver. While my CPU can handle even full OpenGL with 3D games, I don't care to waste it on mere compositing.

> Wayland is impossible to keylog.

This is an incorrect assessment of the claim which is, "with Wayland it becomes possible to build a system where applications cannot record each-other's events." To the best of my knowledge the only approach with X11 that actually works is running each app with a separate X server. The author points out that being able to register global handlers or programmatically interact with other apps is useful which is why it's possible by asking the compositor nicely. The trick with libinput requires that the system already be pwnd.

Another way of saying the same thing, "you cannot meaningfully sandbox applications that talk to your X server."

> Network Transparency

Is a bad thing and a poor remote desktop solution. Let's say you have a desktop with an Nvidia graphics card and you've installed their drivers. Your laptop is using the OSS Intel drivers. You forward an OpenGL app from your desktop to your laptop -- it will crash. Why? Because Nvidia's libGL expects to talk to a server with Nvidia's GLX extension of the same version.

However, a ton of work is going into getting screencasting and remote desktop working under Wayland in a manner that will let you implement whatever protocol you care to speak on top RDP/VNC.

And VNC currently works on Mutter so I'm not sure why the author is bemoaning it's loss. It's the feature that's getting the most development time right now.

> Multiple clipboards

That's up to the implementor, Wayland had a very general API that's used to exchange data between clients that can be used to implement clipboards in any way the compositor sees fit. Just because GNOME/KDE don't want to maintain it doesn't mean it's not there.

> Restarting ends your session.

If your X server crashes it ends your session too. So this is really an argument that X.org is more stable than Mutter/Kwin. I don't think the devs will argue with that but the point is that they'll get there.

> Multiple clipboards

If it's up to the implementer, and two of the biggest options don't do it, then it might as well not exist.

It's open source. You can add support if you so desire. You can even likely get it pushed upstream if what is done makes sense.

I say good riddance to multiple clipboards. We had to fight hard to get rid of it. It is really tiring having to fight off nonsense unintuitive behavior in software.

How are you having to fight it off? If you don't middle click or hit shift-insert, it's invisible. But I find it really useful to trivially move text around with so little friction.

> How are you having to fight it off? If you don't middle click or hit shift-insert, it's invisible. But I find it really useful to trivially move text around with so little friction.

There should be just one clipboard by default and by standard. If some people want non-standard behavior, they are welcome to change things in their dot files or whatever but the default behavior should be sensible. I am not saying copy paste should not be available by middle click or shift insert. What I am saying is that the contents of the two clipboards should be the same by default.

I still don't see what the problem is with leaving them both available by default. You're not harmed by having a second clipboard available if you never use it.

As to setting them to the same content by default: I actually tried that once, because in some ways it would be nice to only have one clipboard to think about, but the problem is that as long as you have the feature enabled that automatically copies anything you select, it's incredibly annoying to work with. And I wouldn't want to disable that feature, because it's most of the convenience that makes the select buffer worth having.

Trusted Solaris had fine grained X Windows security.

In the Year 2000...

http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec12-...

Yeah, but it’s not CADT-compliant: https://www.jwz.org/doc/cadt.html

Thank you.

From what I've seen, Wayland seems to follow a very narrow set of use cases, and willfully ignores others outside its philosophy, no matter what their practical applications might be.

From what I remember reading previously:

- Wine is unimplementable in Wayland. By design.

- Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys. (Desktop enviroments may provide APIs for this, but then you get the foreseeable issues with using e.g. KDE apps on Gnome. And what if you don't want a desktop "environment"?)

- Screenshotting and screen casting tools are unimplementable in Wayland, by design.

- Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.

- I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great.

I can certainly think of situations where Wayland's advantages greatly outweigh its drawbacks, but its philosophy seems so much at odds with at least the way I interact with my computer, that the idea of switching to Wayland seems completely unfathomable. As far as I can see, at this rate, Xorg will live forever.

I've been instead working on my own little tool to fix the few annoyances in Xorg clients that I ran into (the ease with which I've achieved this and the flexibility of the tool speaks further in Xorg's favor):

https://github.com/CyberShadow/hax11

Could you expand on why Wine is unimplementable in Wayland?

Essentially because many Windows APIs are unimplementable in Wayland.

Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=42284

One complaint in this specific thread is that applications can't control the location of their surfaces (which is needed for things like drop-downs and tool tips), but then again sub-surfaces can be controlled by the parent surface. This specific problem does look solveable.

As I understand it from that bug report, the problem is that the Windows app doesn't have to provide any link between the menu or tooltip and the window it's from that's visible to Wine. So your solution basically boils down to modifying every Windows app out there to make it Wayland-compatible, potentially including a bunch of niche industry-specific or even company-specific ones.

There's a similar problem with implementing X on top of Wayland, and so XWayland has special powers that normal apps don't in order to be able to work. That's why running Wine as an X client under XWayland doesn't have this problem.

> One problem is for example that a program can not specify the location of a newly created window.

> It is part of their concept that applications should not have control over the window position and similar settings.

> I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position

Seems excessive

As a user and big fan of tiling window managers, I want the window manager to be the one deciding where windows are positioned, not the application that owns the window. But hey, we can have different tastes and preferences.

That's fine for the majority of Linux apps, but being so strict could impact cross-platform apps that don't understand those assumptions, and then they don't work well at all. For example, the interactive brokers Java application is written in a cross-platform way that makes use of many popup menus. I would hate my choice of wm saying, no, you cannot effectively use this software because it doesn't conform to our windowing constraints.

And yes, I use i3, so I am a fan of tiling windomanagers too. Not everything nicely fits into such a box though, and it's better err on the side of compatibility here, than say, can't use that app, sorry

In those cases, why not just have the window manager lie to the application and say, effectively, "your request to position the window at the coordinates you specify has been fulfilled", but actually position the window where the window manager wants?

That way those java apps would still work, right?

Sure, if it actually works

> I want the window manager to be the one deciding where windows are positioned

It still can, the client merely gives size hints. It is entirely up to the window manager whether it honours them.

> Wine is unimplementable in Wayland. By design.

What, why?

> Screenshotting and screen casting tools are unimplementable in Wayland, by design.

They're not implementable without specific privileges or protocols and that is a very good thing. I don't want my calculator app to be able to record eveything on my screen.

> I use the X forwarding feature so often that I have a hotkey on my laptop

This seems like your very specific use case (and wouldn't be impossible in Wayland).

> Screenshotting and screen casting tools are unimplementable in Wayland, by design

i don't think this is true...i'm pretty sure i've screenshotted desktops before when using GNOME on Wayland.

Those tools were likely not using Wayland protocol APIs, but extensions specific to the desktop environment you were using.

>Wine is unimplementable in Wayland. By design.

This is false. Wine could be implemented, it would just be less easy than on X11 because it uses relative coordinates for everything. But it's totally possible to convert absolute coords to relative coords and use e.g. wl_subsurface.

>Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys.

Yes. This is by design, because it's very easy to turn a global hotkey mechanism into a keylogger mechanism. Also it's not clear how hotkey conflicts should be handled.

Note that there are protocol proposals for global hotkeys.

>Screenshotting and screen casting tools are unimplementable in Wayland, by design.

They already work. See xdg-desktop-portal.

> Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.

That's how it works. Wayland doesn't have the magical power to make everybody implement a common interface. For an interface to be implemented, compositor writers and desktop developers have to agree on a design. Drew DeVault said on IRC something that sums up the situation quite well: "Asking wayland for hotkey management is like asking the HTTP standards group for a new HTML element".

> This is false. Wine could be implemented, [...]

Is the information in this bug outdated?

https://bugs.winehq.org/show_bug.cgi?id=42284

> Yes. This is by design, because it's very easy to turn a global hotkey mechanism into a keylogger mechanism. Also it's not clear how hotkey conflicts should be handled.

It doesn't change that this impacts usability, and a lot of software will need significant updates to accommodate these limitations.

> They already work. See xdg-desktop-portal.

As I understand, xdg-desktop-portal is one competing mechanism among several.

> That's how it works. Wayland doesn't have the magical power to make everybody implement a common interface.

I don't understand... by "a common interface", how would that differ in concept from the X11 protocol?

A new common interface can be better designed and take security levels, permissions, ... into account, instead of giving everything access to all windows?

> Is the information in this bug outdated?

This comment suggests the same thing as me: https://bugs.winehq.org/show_bug.cgi?id=42284#c8

> It doesn't change that this impacts usability, and a lot of software will need significant updates to accommodate these limitations.

Yes, software needs to be updated to work with Wayland. Though, I'm not personally using a lot of software having global hotkeys, and I can configure global hotkeys in my compositor when needed.

> As I understand, xdg-desktop-portal is one competing mechanism among several.

It's the most widely supported mechanism. Works on GNOME and KDE, and support for Sway (and more generally wlroots) is WIP.

> I don't understand... by "a common interface", how would that differ in concept from the X11 protocol?

In the X11 world, all WMs didn't have to agree on a screen capture protocol.

Note that there are discussions in progress to improve communication between Wayland compositor writers.

I think sway just got support for relative coordinates.

Sway got support for relative-pointer, but it's unrelated to positioning surfaces.

I see, my mistake.

> Asking wayland for hotkey management is like asking the HTTP standards group for a new HTML element

It sounds like there is no equivalent of HTML though, and X used to provide an HTML-level API for which there is now no standard. It's a pretty fair criticism of Wayland if it requires developers to re-invent a common interface to get functionality that was previously available through X.

>- Wine is unimplementable in Wayland. By design.

This is a complicated issue which requires a lot of background to explain and answering it in full beyond my patience.

>- Programs cannot set their own hotkeys in Wayland.

This is a feature, not a bug. Why should clients be responsible for dealing with conflicts between programs that use the same hotkey? What if the user wants to pick a different hotkey? Add keylogging concerns on top of that and the argument for this feature becomes pretty weak. Programs designed with Wayland in mind provide some kind of executable that can be bound to a key in the compositor to interact with their daemon.

>- Screenshotting and screen casting tools are unimplementable in Wayland, by design.

This is a lie, or at least a falsehood born from ignorance.

https://github.com/swaywm/wlroots/blob/master/protocol/wlr-s...

https://github.com/swaywm/wlroots/blob/master/protocol/wlr-e...

>These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.

A strong majority of Wayland compositors support these protocols, and talks are underway to improve the standardization process.

>- I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great.

X forwarding still works with Xwayland. Nothing was broken - we have tools for backwards compatability where Wayland is still catching up. Desktops are complicated and it takes a long time and a lot of work to implement them.

But no one is making you switch to Wayland. Keep using Xorg. I doubt you were going to switch anyway, the least you could do is stop spreading FUD.

So wrt the hot key thing, is it possible to have window manager (or an application within an existing window manager) to allow control of window positions and sizes using keys? Something like xmonad, or Spectacle in OS X?

This is possible on sway, but no one has made standards for it yet (it would be pretty contentious, and some groundwork should probably be laid first).

Sway implements the i3 IPC protocol, which has commands for moving windows around. You could bind this stuff to keys if you wish.

> This is a feature, not a bug.

I think you have missed a few important points:

- There is value in installing a program with a known set of hotkeys and having it work out-of-the-box.

- The arguments apply to new software, but I'm not sure they justify the effort imposed on existing software.

- Fragmentation is a big problem. There is a matrix of (number of Wayland implementations / API extension) x (number of software attempting to use Wayland protocol extensions), and gaps in this matrix result in non-working software and unhappy users.

> What if the user wants to pick a different hotkey?

What if the user wants to use a different font or color in the GUI? Reasonable software will have reasonable settings configurable; unreasonable software won't. In any case, this is a solved problem in other, even non-Linux desktop environments as well.

> Add keylogging concerns on top of that

How strong are the keylogging concerns? An effective keylogger needs to either listen to keystrokes passively, or capture then retranslate them. Wouldn't allowing programs to assign hotkeys but not allowing them to emit keyboard events solve this issue?

> This is a lie, or at least a falsehood born from ignorance.

Correct me if I'm wrong, but the links you provided seem to describe a protocol extension. I believe I was unambiguous in that I specifically mentioned Wayland, not a particular implementation.

> A strong majority of Wayland compositors support these protocols, and talks are underway to improve the standardization process.

Standardization is good, but until this becomes a reality, I believe the criticisms stand, and it would be unfair to dismiss them.

> But no one is making you switch to Wayland. Keep using Xorg. I doubt you were going to switch anyway, the least you could do is stop spreading FUD.

Nice to see you taking this so well.

>- There is value in installing a program with a known set of hotkeys and having it work out-of-the-box.

It's a matter of taste, and ours differ. Regardless, there has been some discussion about hotkey protocols. I encourage you to participate.

>What if the user wants to use a different font or color in the GUI? Reasonable software will have reasonable settings configurable; unreasonable software won't. In any case, this is a solved problem in other, even non-Linux desktop environments as well.

Wayland compositors aren't responsible for choosing the color of your buttons. They are responsible for dispatching keyboard events, however.

>How strong are the keylogging concerns? An effective keylogger needs to either listen to keystrokes passively, or capture then retranslate them. Wouldn't allowing programs to assign hotkeys but not allowing them to emit keyboard events solve this issue?

Perhaps! You should bring this up when you start the discussion.

>Correct me if I'm wrong, but the links you provided seem to describe a protocol extension. I believe I was unambiguous in that I specifically mentioned Wayland, not a particular implementation.

Another thing Wayland doesn't define: application windows. The core Wayland protocol is very conservative, and protocol extensions are necessary for doing anything useful.

>Standardization is good, but until this becomes a reality, I believe the criticisms stand, and it would be unfair to dismiss them.

There are effective standards which are implemented by many compositors and clients. In my opinion this is good enough to dispell criticism, but we're trying to improve further still.

"Another thing Wayland doesn't define: application windows. The core Wayland protocol is very conservative, and protocol extensions are necessary for doing anything useful."

Could you explain that further? I haven't followed wayland much?

There's a widely supported protocol extension called xdg-shell which is used for desktop application windows:

https://github.com/wayland-project/wayland-protocols/blob/ma...

It sounds like, for wayland to actually be usable, you need to define protocol extensions that bring it to feature parity with X11.

At that point, why not just deprecate and replace the two(?) things that are problematic with X11: the keyboard logging protocol, and lack of access control on screenshots?

Surely, that is easier than reimplementing the entire graphics stack, all window managers, and all applications.

Because X11 is a huge dumpster fire that no one wants to maintain. How would you feel about maintaining a 30 year old legacy piece of software which has changed hands 5-6 times since its inception? Wayland is truly a better design and everyone is in favor of leaving that codebase behind.

Generally, core Wayland is very minimal. It's meant to have only the pieces that are essential for every Wayland implementation, not just desktop window managers. Therefore you have xdg-shell extension which is meant for desktop and its windows, you have ivi-shell which is meant for automotive applications and you can have your own extension if your use case is different enough to need it. Thanks to that, KDE and GNOME don't have to implement any IVI stuff and cars don't have to know how to minimize or maximize a window, which, as a concept, might not even really exist there.

That would (for me at least) break my favourite password manager KeePass, which has a Global Hotkey for "autotype" of passwords.

Regardless of the merits of the article, I don't like "lie", because it implies people deliberately spreading falsehoods, and the comments here so far reflect that tone which makes everyone's life a little worse. We're all in this together; can we please be nicer to each other and not assume bad faith?

> wl_proxy protocol can be LD_PRELOAD to own the entire system without any privilege required

I don't understand this claim. LD_PRELOAD doesn't allow you to do anything you couldn't normally do. It sounds like the claim is if you run Wayland with LD_PRELOAD set, it's vulnerable, but this is a case of what Raymond Chen would call being on the other side of the airtight hatchway.

Not being able to make a keylogger is actually bad thing.

Both X11 and Wayland have poorly designed keyboard events handling (which was defined in XKeyboard spec in 1995). For example, you want to use Ctrl + Shift keys to switch keyboard layouts on release. Simple thing that is working in Windows. You cannot do that in Linux, because:

- if you assign Ctrl + Shift to switch keyboard layout then when these keys are pressed, the event will be consumed and you cannot use combinations like Ctrl + Shift + F (this will be interpreted as Ctrl + F or Shift + F depending on what key you have pressed earlier)

- you cannot make a separate program that would monitor all key presses and releases and switch layout without breaking other programs. In the X server and extensions there is no such feature as "monitoring pressed keys"

The only way to do it reliably is to have a privileged program that would listen to events in /dev/input.

By the way this bug hasn't been fixed for 14 years [1], and instead of fixing it the distributions have been using different hacks and workarounds. Also, they don't warn user that using Ctrl + Shift to switch layout will break hotkeys using these modifiers.

Another issue is remote control programs like VNC. In both X11 and Wayland to emulate user input VNC server muss pass a key number to the X server or Wayland compositor. Not a keysym, not a unicode codepoint, but rather a number of the key on a physical keyboard. Now guess what happens if VNC client's machine has a keyboard layout with characters not present in layout on VNC server's machine? Everything gets broken. Typical solution for this is to find unused key number and patch current keyboard layout before sending a key press event to the X server.

Because of the same reason on-screen keyboards on Linux cannot produce characters not present in keyboard layout. Emoji, for example.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=865

Are you referring specifically to Ctrl + Shift? Because I use Super + Space (think it's default) to switch between languages in Gnome on Fedora with Wayland and it works fine for me, even when an app has focus.

Ctrl + Shift (or Alt + Shift) is what Windows uses so people migrating from Windows often choose this combination. It is actually a poor choice, because you have to remember which layout is selected and make mistakes, so you type something in the wrong layout, notice it and have to delete and retype it again.

A better solution is to use non-modal layout switching, when you have a dedicated key for every layout. On Windows I use left and right Control keys (with a help of a closed-source program), so I always start typing with pressing one of them. But on Linux I cannot use them (I tried to write a program that would listen to /dev/input but found out that you cannot switch layout in Wayland-based Gnome from an external program because there is no API for this).

Super + Space which is used on Macs, is also a poor choice. It is surprising that Apple, which manufactures it own hardware, was unable to just make dedicated keys for different layouts.

>For example, you want to use Ctrl + Shift keys to switch keyboard layouts on release.

This is possible in Wayland, it's up to the compositor.

>Now guess what happens if VNC client's machine has a keyboard layout with characters not present in layout on VNC server's machine?

This seems pretty normal to me. Remote keyboards are just like physical keyboards. Just configure VNC's keyboard to use the correct layout.

(BTW I'm not sure I understand what you mean by "Everything is broken")

>Because of the same reason on-screen keyboards on Linux cannot produce characters not present in keyboard layout. Emoji, for example.

I don't know about X11's status on this, however in Wayland on-screen keyboards _can_ send unicode to the compositor via the standard text-input protocol [1].

[1]: https://github.com/wayland-project/wayland-protocols/blob/ma...

> ... up to the compositor.

Is there anything like W3C or WHATWG for Wayland?

We had implementation specific extension in HTML, and we all hate that until the browser implentor sat together.

> This is possible in Wayland, it's up to the compositor.

Typically compositor uses libxkbcommon which suffers from the same problems that X server had.

> Remote keyboards are just like physical keyboards. Just configure VNC's keyboard to use the correct layout.

It is inconvenient and I don't think it would work. There is no such thing as "VNC keyboard". VNC client sends keysyms over the wire, so the VNC server has to convert them back to a key number, switch to necessary layout if there are several of them, turn off modifiers like Shift if necessary. This is too complicated. For example, x11vnc server doesn't support non-latin input correctly.

> (BTW I'm not sure I understand what you mean by "Everything is broken")

That many VNC servers cannot handle non-latin input correctly.

> however in Wayland on-screen keyboards _can_ send unicode to the compositor via the standard text-input protocol

This looks like an extension for implementing IME. You can see that there is no key press or key release events. These events are defined in wayland protocol spec [1] and they still use a key number. So you cannot send key press/release events for characters not present in current keyboard layout.

[1] https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

> Multiple clipboards provide flexibility and power. I will be the first to admit that a great deal of people don’t know about this feature, and it is entirely possible to use a computer without it (look at Windows or the Mac OS). That doesn’t mean that I would enjoy losing it, however.

macOS sort of has multiple clipboards, if you squint just right, but they aren't all equally supported.

Select "aaa", command-C, then put your cursor at the front of "bbb", control-K. You can paste the former with command-V, and the latter with control-Y (just like Emacs). The kill buffer is just for text, and has basically no API, so third-party programs can't (easily) use it.

There's also the search selection (command-E), which is pretty much only usable for moving the selection to the search box. It's another semi-persistent way to save some text, though.

The situation reminds me of the 6502 (which has 3 registers, each with specific duties), or the 3 robots of Robot Odyssey.

> There's also the search selection (command-E), which is pretty much only usable for moving the selection to the search box.

In most apps, Command-E followed by Command-G will search for the selected text without even going through the search box!

I can absolutely relate to 4). Getting kicked out of the graphical environment every time sway crashes is frustrating enough for me to abandon it at least until 1.0.

The Nvidia issue is also annoying, why it has taken so long to resolve is hard to comprehend.

They say and wlroots off master. I have only had a single crash, and that was many months ago.

I do keep it fairly updated.

Maybe I've just been unlucky, or maybe it's a nouveau issue but I've had a fair few to the point that I'm not quite confident enough to use it yet.

I'm a great admirer of what the developers have achieved with sway / wlroots though and looking forward to being able to use it full time.

I do have a sway crash every week or so, next time it happens i'll try to investigate. Nothing unbearable tho, the upside of running new software is seeing the edges getting softer (and sometimes helping with that process).

Until Wayland supports X-style remoting of applications, I literally can't use it, so here's hoping X remains an option for a long time to come.

(Edit: Or Wayland implements X-style remoting which would probably be the preferable option since in other respects such as client-side rendering using the GPU Wayland is cleaner)

>Until Wayland supports X-style remoting of applications, I literally can't use it, so here's hoping X remains an option for a long time to come.

Xwayland supports X forwarding, so your existing forwarding setup will work fine OOTB. What's missing is forwarding native Wayland applications, but if everything you use today works on X11, it'll work on a Wayland compositor via Xwayland too.

> Network transparency allows you to run an X11 application from any computer on your network and display it on your local computer.

This is a rubbish point. Remote X may work OKish over a wired LAN, but over anything else it sucks. Not even NX uses the X11 protocol any more.

Honestly the only reason people even use it over a LAN is because VNC is so archaic and nobody has written a modern version. Wayland actually makes that easier though.

The point about crashing compositors is good though. Windows can handle a crash in the graphics driver seamlessly. I don't think any Wayland compositors can come close to that.

> Remote X may work OKish over a wired LAN, but over anything else it sucks.

It depends entirely on the software. E.g., Emacs is great (and even kinda usable across the ocean), while Firefox and most Qt/GTK programs are much less so.

For the Qt applications, try setting QT_GRAPHICSSYSTEM=native. I did experience Qt applications pushing whole window-sized bitmaps until I discovered this.

Now remote $DISPLAY works well again. It seems the functionality is there, just the default setting gives poor performance over the network.

I agree, good software works over wireless LAN with no issues. At my workplace this is used extensively.

Applications that use X11 properly don't just work OKish over wired LAN, but work good enough that you can't tell it's not running locally..

One usual workflow is to ssh into a data reduction machine, do some reduction task and inspect the data products without having to copy them to the local machine or use NFS or the likes to access the files.

What is a data reduction machine?

In my case a few beefy servers (lots of cpu cores, ram and disk) that are dedicated to the purpose of running data analysis/reduction on them.

It work really well until some time around kde3, when people start using client side compose and font rendering.

Try something written in Tk.

> You can achieve pretty much the same isolation as Wayland on X11 with cgroups and Xephyr.

Wait, you mean I could get something almost as good just by adding in two additional technologies to the mix? Amazing!

Adding just one application (Xephyr) is a whole lot easier than replacing X, though. It's probably worse for isolation, but it's also probably good enough.

Several points made in this article are false, misleading, or complete horseshit.

1. > Except the fact that Wayland is based around libinput, which is trivial to record key events from.

This is complete horseshit. You cannot "record key events from libinput", because libinput merely processes key events from evdev in the kernel, received via /dev/input/event*. This is exactly the same as on X.

2. > Wayland’s compositing protocol is basically designed from the ground up to require the kind of closed-source, blob-filled graphics driver from AMD or Nvidia

This is malicious FUD. sway's authors have specifically and repeatedly stated that they explicitly do not support AMD and nVidia proprietary drivers.

3. > Network transparency ... allows you to run something like a Web browser on a more powerful device while running X11 locally

This is true but misleading. If you actually try to run a modern web browser, you'll find that the experience is usable but extremely poor. The graphics are ugly, it's slow to respond, and videos don't work properly.

Re: 3

A lot of people keep saying this about X apps but anything written with GTK will be awful because (from what I understand) it’s just paints everything itself and then uses X11 to actually display what it draws. Plus if you run anything over the network like that GLX doesn’t work.

My main two personal complaints with wayland is that writing simple programs without widget libraries is much harder and that the window management is handled by the app (which IMO makes absolutely no sense but maybe there’s something I’m missing, which isn’t crazy since the last time I messed with it was a year or two ago.)

Until those two things get dealt with I’m unwilling to use it.

> A lot of people keep saying this about X apps but anything written with GTK will be awful because (from what I understand) it’s just paints everything itself and then uses X11 to actually display what it draws. Plus if you run anything over the network like that GLX doesn’t work.

I don't find that to be true, e.g. I've used pavucontrol (a GTK3 app) over the wifi X11 networking and it worked fine - the very nice thing with X11 networking is that it will use your client DPI for rendering / Xresources / etc... so you can have both lo-dpi and hi-dpi clients connecting to the same machine and it works for both without any configuration.

Wow, you got audio playback working over network X11? How did you do that?

no, i'm running on my laptop a remote instance of pavucontrol which controls the volume of my mediacenter (on which the process effectively runs) - no sound data is being transferred, only volume changes. (though I've also used pulseaudio-dlna to cast audio over the network from linux very easily)

So wayland is just a waste of time or what? Why are the Wayland maintainers doing it then? To hurt users? I don't get it, sorry.

Obviously not, but it is not the solution to all problems, that people make it out to be, and still needs a lot of work.

And really, X11 isn't that bad. Or at least xenocara on OpenBSD, which is what I'm most familiar with and which has addressed some of the more glaring problems.

Well, Wayland has been around for a decade now and is still rarely the default for any given distribution. I think that says a lot about Wayland.

Apart from this being increasingly false (wayland being the default display server for gnome since more than 2 years now), adoption rate is much more correlated to the importance of the component than with the quality of the tool, just look at the history of ipv6. The more a component is part of a low-level core, the longer it will take to replace it with anything. Inertia.

Why do we need the power of GPUs meant for fast and complex 3D graphics applications to draw 2D text, lines and icons?

Because 3D is just an extra dimension for the same calculations?

The GPU does not accelerate 3D, but the computations (so 3D can be much faster).

Many graphics cards/chipsets/etc. do accelerate 2D operations, unfortunately there's no feasible unified model of a "2D hardware accelerator" the way there is with 3D, so there's no unified support for it in kernel, either. The whole thing is inherently hardware-dependent.

Not anymore; at least not like they used to in 90's and 2000's. Today, they expose some overlays (and some limitations, how they can be used) and that's it.

There is a Nvidia OpenGL extension NV_path_rendering that was intended for accelerating 2d, but it wasn't widely adopted.

Wayland doesn't require you to use GPUs. Only wl_shm is in the core protocol, you can build a software-only Wayland compositor without any hacks, with shared memory.

By the way, Wayland has nothing to do with drawing text, lines and icons. You just give Wayland a bunch of pixels.

That said, using the GPU for compositing is often better for performance and battery savings. It doesn't require anything fancy, GLESv2 is used by many Wayland compositors and is widely available, even on old hardware. It doesn't require proprietary blobs.

To get that load off the CPU mostly.

Also, I think today CPUs, even if fully dedicated to graphics, can't really compete with today high-end GPUs. Graphics processing and output is a highly parallelizable problem which GPU are designed for, but today CPUs are not .

As mentioned by others, you don't actually need a GPU. Weston, the reference compositor implementation, will run in software rendering.

Because people want their desktop to look nice like Android with smooth animations and not like Windows 3.1 with grey rectangular windows and buttons.

And some people want both nice smooth animations and grey rectangular windows and buttons.

If one turns off special effects (compositing) and uses low resolution, even the cheapest mainstream gpu is sufficient to draw 2D text, lines and icons with 60Hz framerate. However, people expect to get more in graphics output than 10-20 years ago, so they buy high-res displays or turn on additional graphics effects in graphics environment - and then, we do need powerful GPUs, because those resolutions and effects require high computing power that is best to provide in a powerful GPU, not powerful CPU.

The most glaring deficiency so far is lack of support for the binary NVIDIA driver in most implementations. The whole affair is rather childish.

The lack of support for standard Linux APIs in the NVIDIA driver, you mean. You're asking compositors to implement this:

    if (nvidia proprietary driver) {
       /* thousands of lines of code */
    } else {
       /* thousands of lines of code */
    }

We cannot debug the proprietary driver. We cannot fix bugs in the proprietary driver. We cannot read the code to understand it's behavior.

Our answer: "no".

Actually, you don't need to read the driver's code to run it. Just provide the environment the driver needs. If you could provide an environment Windows provides for the drivers then you would be able to run Windows' drivers.

> Our answer: "no".

Good thing you are not speaking for KDE and Gnome then.

But KDE and GNOME are quite large organizations which gets financially supported by many tech companies. And they seem to have closer connections with NVIDIA engineers compared to sway and wlroots. I've even heard that NVIDIA was directly contributing the EGLStream backend code for Gnome and KDE (see the links below)

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-B...

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-K...

It's pretty sad that compared to this, sway and wlroots are being completely neglected by NVIDIA. And I think that is precisely why the sway project decided to ditch proprietary NVIDIA driver support.

For me that's totally reasonable. It's for the kernel developers and NVIDIA to sort out.

So far, Wayland is removing legacy cruft and replacing it with newfangled cruft. The Wayland protocol itself is not even well specified in the way that X is - the whole thing is very far from true maturity. Just like, e.g. Pulseaudio, which is apparently now getting replaced by Pipewire.

... beware the GNUluminati

Reply on news.ycombinator.com