Keyboard Grabbing Protocol Proposed For Wayland

[michael-vb]

I hope Compositor implementations will figure out to leave a setting to disable that thing. Because it's one of most annoying things in X11 protocol, when something like VirtualBox intercepts hotkeys of WM every time you switch there.

Re VirtualBox, disable automatic keyboard capture in the global settings.

[Hi-Angel]

What about the controller input problem on X11? Its a pain in the ass for steam big picture mode. Why not just go like android, pop up a messagebox for allowing or disallowing the app to access global input mapping.

I'm not sure if I understood you right, but if you meant that steam doesn't bind gamepad shortcuts globally, then it's rather steam problem, not X11. I.e. if you open VLC, and go to shortcut settings, you can set shortcuts globally with disregrad to DE. You may want to report a feature request for steam.

[cj.wijtmans]

What about the controller input problem on X11? Its a pain in the ass for steam big picture mode. Why not just go like android, pop up a messagebox for allowing or disallowing the app to access global input mapping.

[ssokolow]

Oh, to clarify, when I used the "sending the password file via HTTP" example as something that doesn't require hardware, I was thinking of things which wouldn't already have access to the password file, such as if you were using something like FireJail or Bubblewrap to run Steam or some other WebKit/Blink-embedding application sandboxed away from your normal browser.

(There's an ongoing problem with embeddable browser components not getting patched as quickly as the big browsers, so things which aren't browsers but can perform HTTP requests and/or run JavaScript are a softer target than going directly for the actual browser.)

[ssokolow]

For example, I'm no PowerShell expert, but I know I could craft a bash/dash one-liner to send all Firefox password databases in $HOME/.mozilla/firefox to a remote server using wget or cURL... or just use a much longer and more robust script via the "pipe curl's output into sh" trick all of the hip programming language package managers are using for installation these days.

[ssokolow]

How do they work? "Run dialog" is a separate app, accepting an input for as long as it stays focused. The only way I can think of (I must say, I don't know if it's possible with Wayland) is to create a transparent fullscreen window, and to redirect input keys to other apps. But even then it should, at least, hack around the hotkeys of a compositor (so that upon pressing a "Next windows" hotkey a window wouldn't change), and panel showing the current window (to get hid).

It's impossible to eliminate them entirely, since there have been proofs of concept using USB flash sticks which secretly also expose virtual keyboards and/or mice, but the general idea is to execute a desktop analogue to XSS or CSRF by triggering a run dialog (or something else equally useful) and then using it to fire off a background task to send the browser's password store file or some other high-value, predictably-located file to a waiting server via HTTP POST.

[Hi-Angel]

Yeah. More specifically, to the use case of macro software, there are proof-of-concept exploits which steal information when all they have is "keyboard/mouse scripting" access by relying on the fact that most desktops have global hotkeys for things like the Run dialog which can be relied upon.

How do they work? "Run dialog" is a separate app, accepting an input for as long as it stays focused. The only way I can think of (I must say, I don't know if it's possible with Wayland) is to create a transparent fullscreen window, and to redirect input keys to other apps. But even then it should, at least, hack around the hotkeys of a compositor (so that upon pressing a "Next windows" hotkey a window wouldn't change), and panel showing the current window (to get hid).

[ssokolow]

AFAIK the only app allowed to watch every keypress windows getting is a compositor. That's why they calling the protocol to be secure, i.e. no app can sniff your password, or something. So such a software would rather be an addon to a particular compositor.

Yeah. More specifically, to the use case of macro software, there are proof-of-concept exploits which steal information when all they have is "keyboard/mouse scripting" access by relying on the fact that most desktops have global hotkeys for things like the Run dialog which can be relied upon.

[Hi-Angel]

Can I listen for key presses in other applications then programmatically insert key presses in other applications?

To make macro software in Wayland, such as AutoHotkey or such.

AFAIK the only app allowed to watch every keypress windows getting is a compositor. That's why they calling the protocol to be secure, i.e. no app can sniff your password, or something. So such a software would rather be an addon to a particular compositor.

[guildem]

Your use case is different. I didn't use mouse most of the time — I'm having touch-type ability, and using tiling WM, as well as everything else fine grained to use keyboard. Which is actually cool, so you can lie back in the chair with keyboard on the knees, and to not care of stretching for the mouse. Or you can use netbook without having problems because of cursor management via touchpad.

I think the good compromise is to ask a user whether they want to allow to grub keys, and then remember the choice, with possibility to change it somehow, of course. And it was actually mentioned in the article and the first message on the list, but what's worrying me is that devs upon implementing might forget it, because by no way asking a user could be a part of the protocol.

I agree with your use case, we have all one, and that's why I think Wayland must implement a "full grab" permission to the apps, and then each app can implement settings to forbid some client shortcuts, or more. And I don't think "real" Wayland compositors will forget to ask users for those permissions. It would be a bad move for the compositor to forget it. Same for the vm managers, if they forget this future option, then they are not as good as they think