Hacker News Reader

Comment by maggit | Hacker News Reader

For completeness; Wayland also protects against keyloggers. In Wayland, input events are sent only to the application that hosts the window into which the input goes. So, keyboard events go to the app that has the keyboard focus.

I'm not sure exactly how X works here. I think as long as you have a visible window (1x1 pixel or more), you can get all keyboard input.

This may or may not be central to your point, but I wanted to have it out there to better inform about how Wayland improves upon X :)

View on HN

Yes and no. Wayland protects from userspace keyloggers after libevent gets its hands on a keystroke. (For that matter, it also doesn't protect against screenscrapers that simply look at video memory.)

Doesn't exploiting both of those require root privileges? Protecting against malicious code running as root seems like a lost cause anyways..

In a system that doesn't use capabilities, generally yes (though, again, even simply with group ownership of devices you can do a lot of stuff that in traditional configurations requires root). But capabilities have managed to sneak into everything nowadays.

Once you have regular user access, root is easy:

http://security.stackexchange.com/questions/119410/why-shoul...

Funny you should bring that up, I was thinking the other day that Wayland should be usable building block for "secure desktop" style thing, that would help to prevent many (if not all) of the vectors presented at your link.

Admittedly I haven't studied this in detail, so maybe there are some fatal aspects in Wayland that would make my ideas infeasible, but I hope that one day we could have more secure desktop privilege authorization.

kinda curious: how would you build something like Text Expander in this world? As a keyboard driver?

Wayland is built up of multiple orthogonal protocols that each app negotiates access to with the server. Any given app will probably use multiple of these, for output, input, etc.

Not knowing exactly what Text Expander is, I'm guessing it would probably need access to a specific protocol for controlling accessibility features. The Wayland server would need to be configured to allow this app access to that protocol somehow, for example by way of a server-initiated popup window that asks you to allow or deny this access.

Does that explain it?

What you mean is that because each compositor would have to add each feature that wayland breaks on each environment some will be implemented badly, others not at all.

Why do that sound very damn close to the various X extensions that has come and gone over the years?

I'm also curious about keyboard layouts. I type stuff in both English and Bengali, and it looks like wayland.ini uses similar semantics to xorg.conf (layout=us,in variant=,ben or something like that). I'm curious how they'll do per-window layouts like windowmaker does. I find those very useful, and I'd assume they depend on some level of message promiscuity that they find distasteful -- I could imagine libevent being "smart" enough to multiplex that like my window manager does, but that in itself gets worrisome for largely the same reasons that people are talking about with X, particularly if it's meant to be extensible (it is, right?)

Why would it be extensible. Instead pick the desktop environment which gets this feature more or less right and hope that some other feature you want isn't only available on a different de.

Reply on news.ycombinator.com