Originally posted by kon14
View Post
Announcement
Collapse
No announcement yet.
Wayland Testing New Protocol Extension To Handle Session Locking
Collapse
X
-
Originally posted by dpeterc View PostWe used to have security through obscurity.
Now we have security through missing functionality.
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.
- Likes 1
Comment
-
Originally posted by tildearrow View PostNice. 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...
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.
Originally posted by kon14 View PostA portal for global hotkeys is actually in the works.
Originally posted by tildearrow View PostFinally...
We have received several requests from elementary AppCenter app developers for a way to set (or prompt a user to set) a global keyboard shortcut to launch their app or a specific feature of their a...
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)
On X11, I use XGrabKey because I refuse to implement a separate backend for every desktop.
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.
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.
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.
- Likes 1
Comment
-
Originally posted by khnazile View PostWhat 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?
Upon encountering an error when dispatching or flushing because we lost connection (EPIPE or ECONNRESET) we attempt to reconnect to the compositor and reset our state to match...
The stuff is slowly progressing forwards being added to toolkits and compositors so it can work. This is just not a fast process.
Comment
-
Originally posted by kon14 View Post
I am a maintainer of the ActivityWatch project and we are polling the currently focused windows name and title. This is not an issue under Xorg but on Wayland this is a problem as there is no commo...
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.
Comment
-
Originally posted by johanb View Post
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.
I am a maintainer of the ActivityWatch project and we are polling the currently focused windows name and title. This is not an issue under Xorg but on Wayland this is a problem as there is no commo...
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.
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.
Comment
-
Originally posted by xfcemint View PostAdding 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.
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.
Comment
-
Originally posted by oiaohm View PostThis 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.
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.
Comment
-
Originally posted by xfcemint View PostYou 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 people wonder why anti-cheat doesn't work on Linux.
Comment
Comment