Wayland Testing New Protocol Extension To Handle Session Locking

[tildearrow]

A portal for global hotkeys is actually in the works.

https://github.com/flatpak/xdg-desktop-portal/issues/624

Finally...

[Ironmask]

We used to have security through obscurity.
Now we have security through missing functionality.

Software then: You can do literally everything
Software now: You can do literally nothing

How hard is it to just, I dunno, ask me what I want software to be allowed to do? As much of a joke as Android is, this is the one thing it gets partially right.

[oiaohm]

Nice. But this is proof that "privileged" protocols are possible on Wayland, so why not a protocol to query mouse position or window status, or one to add hotkeys...

Adding hotkeys does not make sense at all to be in the wayland protocol. The others query mouse and windows status this new addition does not help their cause at all. This new protocol to handle screen locking is about not having the wayland compositor handle authentication. Yes off load screen locking to different process now means wayland compositor does not have to have the privilege to perform user validation.

Now looking up mouse position or windows status you want user/process validation these are different class of problem to the screen locker. Screen locker you are getting validation out of the wayland compositor to a privilege process. Notice something windows status and mouse position you will be doing the exact other way you will be wanting validation in Wayland compositor.... see problem.

Validation code in wayland compositor is overhead you don't want there.

A portal for global hotkeys is actually in the works.

This is good to see.

Finally...

This is portal solution is not by wayland protocol but a dbus protocol.

https://github.com/flatpak/xdg-desktop-portal/issues/624#issuecomment-1024731337

Now lets take ssokolow post here 4 points you start seeing

Any solution that meets my needs must have as little latency as feasibly possible. (I say this as someone who tends to load down his systems such that fork/exec-based keybinding gets noticeably sluggish)

This point 1 leads to problem because ssokolow here is not being exact enough. Lowest latency is directly use libinput and have permission to directly to the input devices for hotkeys but this has no validation if some other software is grabbing the input and is a massive security nightmare. Yes libinput path is faster than using XGrabKey as well. So you want hotkey and validation if some other application is using it and maybe a few more features like means to remap hotkeys without application involvement.

On X11, I use XGrabKey because I refuse to implement a separate backend for every desktop.

XGrabKey has it problems. If some other process has beaten you to punch and grabbed a hotkey you cannot change it.

Given that I tend to use things that register half a dozen or more global hotkeys (eg. I'm still on the GTK version of Audacious Media Player because, last I checked, global hotkeys were listed as not-yet-reimplemented for the Qt UI and I use Win+... for all interaction), the current state of global keybinding in Wayland has been one of the things keeping me on X11 since I don't consider it acceptable to have to manually bind everything.

The reality here is the mess need sorting out under X11 as well

It's always felt like a massive wart in the ecosystem, even in the heart of the X11 era, that you have to write a KDE-specific backend and use KDE to get a nice cross-sectional "all global hotkeys on the system" control panel capable of identifying potential collisions and the like.

Yes hotkeys with X11 is a wart and a half. Remember applications don't have to use XGrabKey for hotkeys under X11. So yes under X11 is very possible to end up with two or more applications in fact reacting to the same hotkey. Yes X11 debuging interfaces some applications use their hotkey implement ion is just as security broken as directly using libinput to input device and application using this under X11 does not have to use special privileges so hard to find until it causes you hell. Libinput direct to input device there are security things the application has to have and the fact the application has a direct connection to input device giving away its doing this horrible thing.

Little bit of latency cost to be able to report to users about collisions and possible in the service handling hotkeys be able remaps. Lets say application asks for alt-f4 you know this will be taken being able to create a rule to say when this application asks for alt-f4 assign it some other hotkey would be good in some use cases. (think running wayland compositor inside another wayland compositor)

Hotkeys there does need to be some serous debate. I personally think the xdg-portal idea is the best move. Yes this comes a dbus service this has validation by polkit so you could blacklist application from being able to setup global hotkeys at all that could be useful.

The feature set people want on their hotkey management solution may not be the same so you don't want the extra code to remap hotkeys causing extra latency if you never use that feature. So do you want to have to choose your hotkey management feature set when you choose you wayland compositor?? I would say most likely no.

Is it possible to copy what KDE has implemented for hotkeys using a dbus service without the wayland compositor containing any support code the answer is yes due to the libinput straight bipass everything option.

Yes a service based hotkey solution based around xdg-portal means users could change there xdg-portal for hotkeys.

A user might want to have multi keymaps hotkeys they can press a hot key to change between as well this is a feature we cannot do with the current X11 design. Yes people buy macro keyboards to get this kind of feature. Yes this would be allow application to register a hotkey but pressing that key on the keyboard only works if keyboard is in particular mode/layer.

Some of this is not do as good as X11 does but we need to admit X11 in the area is broken and we need a better design. Yes designing a better design is not easy.

[khnazile]

What about compositor robustness/crash handling/handoffs? KDE worked on it, but I see no mention of it for Plasma 5.24, nor any efforts to add some standard protocol for this. Was this idea refused?

[oiaohm]

What about compositor robustness/crash handling/handoffs? KDE worked on it, but I see no mention of it for Plasma 5.24, nor any efforts to add some standard protocol for this. Was this idea refused?

The reality here if you watch the presentation you find out that there was zero changes to the Wayland protocol. Its handling code in the toolkits and the compositor sides that it works. So the idea has not been refused but it taking while.

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4073

The stuff is slowly progressing forwards being added to toolkits and compositors so it can work. This is just not a fast process.

[johanb]

A portal for global hotkeys is actually in the works.

https://github.com/flatpak/xdg-desktop-portal/issues/624

Regarding a portal for querying window status though, I created a GitHub issue for that 2019 and since the feedback from the xdg-desktop-portal maintainers were negative I have not proceeded with trying to fix it.

https://github.com/flatpak/xdg-desktop-portal/issues/304

I have however been dirty and used the foreign-toplevel-management API in xdg-portal-wlr for sway which works, but since that API is intended for bars I think slightly annoyed one of the sway maintainers when mentioning that.

[oiaohm]

Regarding a portal for querying window status though, I created a GitHub issue for that 2019 and since the feedback from the xdg-desktop-portal maintainers were negative I have not proceeded with trying to fix it.

https://github.com/flatpak/xdg-desktop-portal/issues/304

I have however been dirty and used the foreign-toplevel-management API in xdg-portal-wlr for sway which works, but since that API is intended for bars I think slightly annoyed one of the sway maintainers when mentioning that.

This is a more complex problem. The problem here is should this be in xdg-desktop-portal or should this be in atspi2 remember these are both dbus protocols.

atspi2 is for items like screen readers and custom input devices. Yes atspi2 for screen readers does need to know what is the current windows status also when you have accessibility features enabled on many applications this provides a more secure way of doing input so that input can be put into particular applications input boxes without user mouse or keyboard actions screwed it up.

See the problem here. After you have got the windows status what are you going to want to do? Input into the application into particular boxes like username and password boxes if so that accessibility. This is where the xdg desktop portal developers stall is coming from. They don't want to end up having to complete re-implement atspi2. Also application developers like those of keepass don't want to have to ask users to turn on accessibility so their application works. Remember accessibility can be turn on per application so not a universal door key.

[oiaohm]

Adding a protocol/API for hotkeys is OK, but the OS or compositor must be able to show the privileged allow/deny dialogues and to centrally manage all hotkeys.

There is a big question of compositor should be managing hotkeys. KDE has a dbus service for managing all hotkeys that is not depending on the compositor to do the heavy lifting. Same with allow and deny dialogues. This new protocol for session locking has application that is not the compositor rendering the allow/deny dialogues. Think about MS windows UAC windows are not in fact created by the MS windows compositor.

This is where things get tricking. You don't want to shove everything into the compositor because then you have the compositor itself with too many privileges.

[ssokolow]

This point 1 leads to problem because ssokolow here is not being exact enough. Lowest latency is directly use libinput and have permission to directly to the input devices for hotkeys but this has no validation if some other software is grabbing the input and is a massive security nightmare. Yes libinput path is faster than using XGrabKey as well. So you want hotkey and validation if some other application is using it and maybe a few more features like means to remap hotkeys without application involvement.

Note that I said "as feasibly possible". I was mainly talking about not having to indirect through stuff like fork/exec or D-Bus Activation APIs designed by people who assume everyone has an SSD and a hexacore CPU or other stuff like that.

Just use the same mechanism already used for grabbing global hotkeys for the compositor itself or manually-configured global keybinds, then dispatch the events over whatever form of IPC is feasible. Ideally the Wayland socket like any other event since that wouldn't require waking up the D-Bus daemon but D-Bus to an already-running application is better than nothing.

[Weasel]

You have to consider those features from the perspective of security, privacy and sandboxing. An application should not know anything about the computer system it is running on, except for the informatoin that a user allows as accessible (the user must always be 100% in control).

For example, the application cannot know what GPU or CPU is installed, and it is none of it's business. App can benchmark the GPU and CPU to figure out the actual speed. If this security point is disregarded, then the user gets susceptible to indentification by hardware fingerprinting. The OpenGL and Vulkan APIs provide all the necessary functionality for interacting with GPU.

Also, the OS is absolutely allowed to lie to the application. OS should be able to simulate virtual keyboards, virtual gamepads, virtual key presses, macros, virtual GPUs, and so on.

In this situation, your proposal is to allow the application to read the ACTUAL position of the mouse. This is incompatible with privacy, sandboxing and anti-fingerprinting. Whether the application should be allowed to read the mouse position should be the discretion of the user: he can allow it, or not (the OS can emulate the mouse position so that the app thinks that it can always read it). At the minimum, this needs to be a part of a security policy for each particular application (like, a dialog pops up asking whether to allow or disallow).

The point is: the user has no alternative but to trust the OS and the CPU, but applications should not be trusted, and do not need to be trusted. That way the user can run any application, including malitious applications, without any compromise in security. So, it allows more freedom for the user (he can run any application without fear).

Adding a protocol/API for hotkeys is OK, but the OS or compositor must be able to show the privileged allow/deny dialogues and to centrally manage all hotkeys.

And this is why people have to run everything under Admin on Windows. I guess soon many apps in Linux will require root for no reason because of this dumb "privacy" and sandboxing bullshit.

And people wonder why anti-cheat doesn't work on Linux.