Wayland Testing New Protocol Extension To Handle Session Locking

[tildearrow]

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.

You forgot about the fact that a future protocol for reading mouse position, window status, and some other things (as I like to call it "data query") will require a permission system, to ensure applications cannot do so without the user's consent.

[oiaohm]

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.

I thought this was the problem.
https://github.com/KDE/kglobalaccel/...lobalAccel.xml
Yes this is the KDE example of how to do global hotkeys using dbus. You will notice there are some serous differences. The means to inform application that user from a single interface has changed the hotkey so allow application to update it dialogs with what the current hotkey is. If we wish for single location management of hotkeys there is need for more communication paths than wayland is really designed for. Dbus is designed for the as well.

Over the wayland socket you run into problem its not designed to have authentication system. Yes X11 and other OS setting up hot keys you did not think about Authentication and this is because you did not have a global hotkey management.

Yes the overhead of kglobalaccel does not require SSD or hexacore CPU. Remember this is a dbus communicating and activate service. Dbus allows on demand activated services. Yes this is services that once in use remain running.

There is a crash thing to consider here kglobalaccel can crash under KDE without taking out the complete interface. Yes global short keys stop working and that it and with dbus it is possible for applications to pick up that kglobalaccel died and reinit their global shortcut keys. Yes X11 global short cut handling in the past has had bugs and crashed the complete X11 server.

So D-Bus daemon to D-Bus activated service that most likely going to be already running because the desktop envornment or something else will have setup a hotkey before you application wants to means the cost is normally low.

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.

This is no. Sandboxes like flatpak forbid applications running as root. This has lead to portals and other dbus interfaces for different things.

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

When all the major anti-cheat solutions work on Linux today because of the Steam Deck without needing kernel mode driver or extra privilege above that of a normal user. Please note those same major anti-cheat solutions under MS Windows require kernel mode drivers and running games as administrator users. The reality is that extra stuff is not justified by the results. Those who are going to cheat in games have people developed ways around all the different forms of anti-cheat that run on the users computer. Of course the fact using kernel mode anti-cheat results in kernel mode anti-anti-cheat that then results in kernel mode malware shipped with anti-anti-cheat and other software.

The reality here is kernel mode and high privilege anti-cheat really does not provide any advantage over user mode anti-cheat other than having more people skilled at writing high privilege and kernel mode malware. Yes games all these massively invasive anti-cheat solutions has not prevent users from cheating in their games. Server side anti-cheat generally is more effective because the user has no means to tamper with the anti-cheat.

Also once you dig into anti-anti-cheat developers what they are doing you find Microsoft drivers are in a bigger mess than what you think. As they maintain lists of known signed vulnerable drivers that they can get their code into kernel mode using Microsoft approved drivers. Yes this include drivers have have been known security flawed for over 10 years now with vendor replacements.

Anti-cheat is a very bad place to go Weasel if you are attempting to argue against the Linux way of doing things. Long term the lower privilege is the right move. Hard part has been convincing those developing Anti-cheat of that case as they have had the mind set that as their anti-cheat got beaten they would just keep on going to higher and higher privilege in the system and the anti-anti-cheat developers just followed them in increasing privilege progressively defeating them. Of course the fall out has been players who don't cheat end up with all the bad side effects of the anti-cheat and the cheaters with the different anti-anti-cheats end up with a better game so ant-cheat end up harming rule following users. Same we see happening with digital rights management as well.

You forgot about the fact that a future protocol for reading mouse position, window status, and some other things (as I like to call it "data query") will require a permission system, to ensure applications cannot do so without the user's consent.

That is the bit that means they are not wayland protocol. xace that attempted to add permission system to X11 protocol end up causing tones performance problems.

[tildearrow]

That is the bit that means they are not wayland protocol. xace that attempted to add permission system to X11 protocol end up causing tones performance problems.

Please don't bring up the abomination called XACE to the table. It's like Windows XP's "secure mode".
In XACE you either allow or deny permissions without a chance to get asked whether to allow it or not AT RUNTIME, which is why it failed and nobody uses it.
What I meant is something like macOS or Android. A normal permission system.

[oiaohm]

Please don't bring up the abomination called XACE to the table. It's like Windows XP's "safe mode".
In XACE you either allow or deny permissions without a chance to get asked whether to allow it or not AT RUNTIME, which is why it failed and nobody uses it.
What I meant is something like macOS or Android. A normal permission system.

This shows lack of understanding of XACE history.

https://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html

The X Access Control Extension (XACE) is a set of generic "hooks" that can be used by other X extensions to perform access checks. The goal of XACE is to prevent clutter in the core dix/os code by providing a common mechanism for doing these sorts of checks. The concept is identical to the Linux Security Module (LSM) in the Linux Kernel.

Do note this says other X extensions to perform access check. Solaris Trusted Extensions did have the option of at runtime to ask user if something should be allow or deny with XACE. Yes Solaris Trusted Extensions did have the possibility of the most horrible miss configuration where the dialog asking for permissions allow and deny had no assigned XACE state so now you now have a never ending loop lockup as its opening the dialog to ask for allow/deny over and over again to find out if the prior allow and deny dialog should have permission.

Android user interactive permissions are done over binder basically androids answer to dbus. Macos user permissions are also done avoiding the compositor protocol.and its done the notification system what is Macos closest built in analog to dbus. So that so called normal OS permission system on every os is not using their equal wayland socket. Yes even windows UAC is not using the compositor interface for any permission stuff that cannot be auto granted.

tildearrow the reality here like it or not lot of things you are asking for to be done by wayland is asking for the abomination called XACE to be particular the Solaris version of that abomination. Yes the fact that all OS other than Linux basically use something like dbus for the tasks should give you serous reason why dbus for lot of things should be consider the first option.

[ssokolow]

I thought this was the problem.
https://github.com/KDE/kglobalaccel/...lobalAccel.xml
Yes this is the KDE example of how to do global hotkeys using dbus. You will notice there are some serous differences. The means to inform application that user from a single interface has changed the hotkey so allow application to update it dialogs with what the current hotkey is. If we wish for single location management of hotkeys there is need for more communication paths than wayland is really designed for. Dbus is designed for the as well.

The compositor already has a mechanism for global hotkeys for its own use. The compositor already has a mechanism for forwarding events to the focused application. From what I remember, compositors usually already have their own proprietary way of implementing global hotkey support with a privileged UI to let the user set i up manually.

All the compositor needs is a D-Bus interface to allow un-privileged applications to request global hotkeys, and a D-Bus interface to allow some privileged application (i.e. the global hotkey control panel) to list and manipulate the requested mappings.

With proper support for privileged APIs, displaying the prompt for whether to allow a request for global hotkeys can be put in the XDG Portal host, leaving the compositor as lean as it already is, aside from splitting the current status quo off so things other than their privileged control panel UI can make requests.

I'm perfectly fine with D-Bus being used for the configuration and activation. I just think it's inefficient and silly to have global hotkeys delivered to an already-running application via a different mechanism than the local ones delivered when the window is focused.

[oiaohm]

I'm perfectly fine with D-Bus being used for the configuration and activation. I just think it's inefficient and silly to have global hotkeys delivered to an already-running application via a different mechanism than the local ones delivered when the window is focused.

This contains a fatal presume and that is Already Running. As applications going forwards become wrapped in cgroups there is every chance that an application that is in background could have its CPU allocation dropped to 0%. So the reality is just because a program has been started has run so far does not equal that its still running cgroups and the like could have basically totally stopped the process because it was background to free up those CPU resources for the other applications.

Active window hotkeys as in local hotkeys and global hotkeys do need to be different things.

Lets say I have application that local hotkey is alt+- and I have a global hotkey that is the same. How should I handle this. There is a reason why you do want global hotkeys to be split so they global hotkeys can be suspended based on what application is active.

Yes it will take getting use to having to treat local hotkey and global hotkey as different things but in the long run it the better option. Local hotkey you can expect the application to be active window and to have CPU and ram allocated. Global hotkey when that pressed application may not have ram or cpu application that right application could have been totally suspend to disc going forwards. Yes you do have the issues of how to deal with global hotkeys conflicting with local application hotkeys as well.

Going forwards global hotkeys with Linux will be a more complex problem. People have not paid attention to kde and gnome implementing systemd as their session manager so putting cgroups around individual applications and this is going to lead over time to more and more resource control.

Yes windows, Macos, android really don't have cgroup level process management around everything.

[oiaohm]

I find this argument not quite convincing. If a desktop program has been run, it either needs to receive the I/O events or be terminated. Desktop applications are interactive. Puting them to background is only allowed if the OS has reserved a sufficient amount of CPU time and resources to bring the application to the foreground.

https://kernc.github.io/xsuspender/

The reality here there is logical problem here. You are thinking that application is in one of two states able to receive I/O and terminated.
The reality going forwards is:
1) "active" window yes this able to receive I/O and has cpu time.
2) background process still has means to use CPU and I/O
3) Suspended in memory by some means like xsuspender and other options yes this has to have reserved enough memory and the application can currently have zero CPU time.
4) Suspended to disc there was a recent presentation as the X11 conference on this with CRIU. So this does not have memory allocated to application state is saved to disc.
5) Terminated.
So when a windows does not have focus you cannot be sure any more that it has any CPU time. Yes there are 5 states application could be in not 2/3. Yes type 4 what is worse because to bring application back from disc other applications may have to go to disc.

Yes putting application in background without enough CPU resources reserved by pushing the application to disc is something android does all the time for power effectiveness reasons.

About "local" and "global" hotkeys: there is a terminological confusion here. For me, there exist only "global hotkeys" and "application hotkeys". Application hotkeys are entirely implemented by the application, so no additional functionality in the OS is required.

Local, active and application different names giving to the same hotkey type. Some cases called foreground hotkey as well. Global hotkey is the one that there is basically 1 name and that it.

I do not furher divide "global hotkeys" into "general" and "local". This is an implementation detail in the hotkey manager (some small extra functionality), that enables it to use a different set of hotkeys if a particular application is focused.

As you attempt to get better and better power management global hotkeys are not longer as simple to process. Because inactive window in a lot of cases equals=zero CPU so you are going to send message to application with zero cpu time so it will only find about about the global hotkey when the application gets allocated CPU time again and it processes the what is in the input que. Yes this might be not until user clicks on window to make it active again without something managing global hotkeys..

Global hotkey manager going forwards is basically required to perform three tasks when handling a global hotkey.
1. find out when application should be messaged about a global hotkey
2. make sure application is in a state to receive messages as in not suspended in some way and if suspended wake it up if required suspend other applications that are not required active so the application can wake up with enough CPU time.
3. give the application the message about the hotkey that was pressed.

This does not look like your historic hotkey problem where you only had foreground, background and terminated process states. So we basically have two more states to deal with and this massively changes the problem.

[Sonadow]

How is screen locking being implemented right now in Wayland?

Either through the compositor or the session manager.

Plasma does it through the compositor.

Gnome does it through the session manager. If Gnome is started from a TTY or a session manager that is not GDM, screen locking is impossible. Even xdg-screensaver lock and loginctl lock-sessons will do nothing.

[oiaohm]

a) I agree that, for power saving scenario, it may might make sense to temporarily suspend the sending of messages to the interactive application. The real question here is what is meant by "temporarily"? Every second / tenth of a second / millisecond? I would argue that the message suspension lasts approximately tenth of a second, because it is a sufficient time for a CPU to engage many power saving mechanisms. I would estimate that 0.1 second time interval is used on majority of mobile phones for power saving. This means that every desktop aplication actually gets at least a small fraction of the CPU time, perhaps 0.001%.

Item like XSuspender we are not talking seconds of sleep. That 5x more battery life your background applications could be without CPU time for hours to days at a time.

b) Also, about suspend to disk / swap to disk, it is not an all-or-none choice. A very small part (less than 1%) of the application can remain in the memory, this part is the one processing the messages.

https://criu.org/Main_Page CRIU works by freesing the state of a cgroup and sending that to disc. So this option is all or none choice. So using CRIU there will not be a very small part of the application left in memory. Application has been basic CPU dropped to zero transfer to disc and memory freed for other applications to use.

c) the message queue buffer can be enlarged so that more messages can wait in the queue. This gives the CPU a larger time interval for power saving.

No that would be a very bad idea. You were thinking temporarily as second or tenth of a second or milliseconds. The suspend background processes I am talking about we are talking hours and days of background processes sitting with no CPU time or memory usage. Really you don't want to have user pressing global hot key hundreds of time waiting for application to return from CRIU and then application getting hit by that storm. Global hotkey manager will need to be smarter.

This is only the tip iceberg. Once applications can be suspended and the application can reconnect to new wayland compositor things will get even tricker.

Completely stopping the processes means more core in the system can go off-line.

d) I don't understand how the "global hotkey manager" that you have described is any better than the hotkey manager that I have described. Both of them need to send messages to the application at about the same frequency.

This is wrong you were not allowing for how far suspended. So a proper "global hotkey manager" to support the future systems will have to support very low latency and have to support digging application that had it state suspended to disc. Like a big application suspended to disc might take min or 10+min to be brought back into memory.

My prior 3 points.
1. find out when application should be messaged about a global hotkey
This has to be fast.
2. make sure application is in a state to receive messages as in not suspended in some way and if suspended wake it up if required suspend other applications that are not required active so the application can wake up with enough CPU time.
This here could be between almost instant and really slow. So yes "global hotkey manager" might be showing a splash screen to user that yes the application they pushed the global hotkey is being restored from disc.

3. give the application the message about the hotkey that was pressed.

This could be again almost instant to really slow as in minutes to a hours to possible longer after the key was press that the application finally gets informed about the global hotkey press.

This future global hotkey stuff is a very different beast. Of course a user maybe wanting be using a different suspend solution. This is why global hotkey in wayland compositor is bad. We need to be able to mix and match the Wayland compositor and the global hotkey manager going forwards.

[ssokolow]

No that would be a very bad idea. You were thinking temporarily as second or tenth of a second or milliseconds. The suspend background processes I am talking about we are talking hours and days of background processes sitting with no CPU time or memory usage. Really you don't want to have user pressing global hot key hundreds of time waiting for application to return from CRIU and then application getting hit by that storm. Global hotkey manager will need to be smarter.

[...]

This future global hotkey stuff is a very different beast. Of course a user maybe wanting be using a different suspend solution. This is why global hotkey in wayland compositor is bad. We need to be able to mix and match the Wayland compositor and the global hotkey manager going forwards.

I still don't see what the problem is.

The events arrive at the compositor. The compositor can do whatever the hell it wants to manage event interaction with the application lifecycle (eg. drop repeats while the application is loading), and then it dispatches them through the Wayland socket, in-line with other events.

Do you know what one of my biggest problems with Firefox is? After all these years, they still have "when the browser is bogged down, events can be processed out of order" bugs.

(eg. If it's bogged down, typing "search keywords" into the address bar and hitting Enter can result in a search for "search keywo" because the "Enter" press jumps the queue. Likewise, if the browser is bogged down, "eb ebay search" could send that as a literal search to DuckDuckGo rather than searching eBay for "ebay search", because you have to stop and wait to be sure it's finished its query for whether "eb" is a keyword first. I don't want global hotkey processing encouraging those same bugs in other applications. It's frustrating and hell on developing muscle memory.)