5 ms·

Screen sharing and screenshots weren't an afterthought. Weston had support for those for a long time, but gnome and kde decided to do something different, proba

Screen sharing and screenshots weren't an afterthought. Weston had support for those for a long time, but gnome and kde decided to do something different, probably because they saw pipewire was maturing. Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want. The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.

zaat 5y ago
> Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?
- taway098123 5y ago
  All of those questions are really irrelevant. The point with Wayland is to make something that's more secure than the systems it aims to replace, not to make exactly the same thing. If you want to help, maybe show a way this can be done without poking a huge security hole? Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
  - michaelmrose 5y ago
    If you don't have any users you will soon find yourself without developers so it is in fact quite relevant.
    - taway098123 5y ago
      That seems like the reverse of the way it's always been on Linux, where there are only developers and no users...
  - zaat 5y ago
    I'm working with i3 (on X, obviously). Perhaps I'm diluted but my experience is that users of this setup are happy about their setup and love the system they use. I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.
    - taway098123 5y ago
      There's plenty of ways to securely multiplex Ethernet devices. You don't give your web server read access to all TCP ports being used by other services for example. You only let it open the HTTP ports. There are of course ways for debuggers to escape this and intercept all TCP packets sent by the kernel, but those require elevated privileges.
    - kaba0 5y ago
      Sway is in top-up form and is basically just i3 on wayland. Even the config is largely compatible, so do give it a try, if you haven’t (recently)!
      - zaat 5y ago
        I tried it not long ago. It's ok, took me some time to overcome some issues but got it to work, then, when I started actually working I met the same issues regarding screenshots, remote control/screen sharing and decided to stay with i3 while I can.
craftinator 5y ago
So I can't log my own keystrokes on Wayland? Anti feature.
- taway098123 5y ago
  If you have root access to your own system, or read access to /dev/input, then it's trivial to deploy a keylogger. No need for Wayland to get involved there. You can't log keys through the Wayland socket because that socket is intended to be accessible to sandboxed programs.
  - michaelmrose 5y ago
    So to be clear you want such a program to be implemented to be running as root in a way that the user can't individually control its just another root daemon that the user may or may not be aware of.
    - taway098123 5y ago
      That's one way to do it, it's probably not the best way but it would work if you were planning to sidestep Wayland security completely. You could make it user controllable with dbus and then make a GUI to talk to it.
    - kaba0 5y ago
      craftinator wanted a way to log his/her own keyboard events. Of course a custom extension can also be created for this use-case, in which way the compositor can allow/deny access for keypresses to specific windows. But to be honest a central hot-key manager where apps can register new bindings (and with compositor managed multiple bindings resolution instead of the ad hoc way under X) would be a great target.
CarelessExpert 5y ago
I've heard all the excuses. None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases, or worse, to make those use cases someone else's problem (e.g. screen sharing), thereby creating fragmentation in the ecosystem due to a lack of standardization. After all, it's pretty rich to blame Gnome or KDE for "[deciding] to do something different" when Wayland was very deliberately designed to offer no standard for how to do the thing in the first place. I'd actually prefer it was unintentional, as that would imply simple oversight. If it was intentional, that implies deliberately bad design choices that have gotten us to the semi-broken place we are right now; a place we're only finally getting out of as other people (e.g. the PipeWire folks) step in to cover up the spike-filled holes that Wayland has left behind.
- taway098123 5y ago
  These aren't excuses, there are no other parties at play here. Weston was the first implementation. GNOME and KDE were the next implementations. They could have chosen to copy Weston's implementation, thus making those parts "standard" but they didn't. That's the way it played out. The way you're talking about it makes it sound like there was some outside force designing Wayland and convincing the other designers to exclude screen sharing, when it wasn't like that at all. You also seem to be suggesting that they could have designed everything in hindsight perfectly before the implementations even existed, I hope I don't need to point out why it doesn't work like that. You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.
  - CarelessExpert 5y ago
    > You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. Given that Wayland was first released in 2008 and the first commit to the PipeWire project was in 2015, I'm quite confident at this point that you're rewriting history to support your position.
pantalaimon 5y ago
> Maybe someone will figure out a good way to do this but I wouldn't hold my breath. Android and iOS and Browsers these days already have figured out something for those kind of things - they ask for permission.
- taway098123 5y ago
  The usual place those permission dialogs have gone is the flatpak portal, which is separate from Wayland. Someone would have to implement it there.
destructionator 5y ago
> Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers https://www.x.org/wiki/Development/Documentation/Security/ https://www.x.org/wiki/Development/Documentation/Security/ The X.Org Foundation released 7.2.0 (aka X11R7.2) on February 15th, 2007. The Wayland devs themselves say "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X." https://wayland.freedesktop.org/faq.html#heading_toc_j_5 https://wayland.freedesktop.org/faq.html#heading_toc_j_5 They just didn't want to.
- the_why_of_y 5y ago
  XACE is basically an extension of SELinux into userspace for X11. Given that today Fedora/RHEL are the only distros that enable SELinux out of the box, such an approach would have been doomed to failure (or doomed to provide a product differentiator for RHEL in the best case) - not to mention the sheer joy and excitement that debugging SELinux AVC denials would produce for end users and desktop application developers. https://www.freedesktop.org/software/XDevConf/x-security-walsh.pdf https://www.freedesktop.org/software/XDevConf/x-security-wal... (Wayland's "buffer exchange and update models" won't provide security on their own without any improvement on the input side)

zaat 5y ago

> Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?

taway098123 5y ago
All of those questions are really irrelevant. The point with Wayland is to make something that's more secure than the systems it aims to replace, not to make exactly the same thing. If you want to help, maybe show a way this can be done without poking a huge security hole? Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
- michaelmrose 5y ago
  If you don't have any users you will soon find yourself without developers so it is in fact quite relevant.
  - taway098123 5y ago
    That seems like the reverse of the way it's always been on Linux, where there are only developers and no users...
- zaat 5y ago
  I'm working with i3 (on X, obviously). Perhaps I'm diluted but my experience is that users of this setup are happy about their setup and love the system they use. I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.
  - taway098123 5y ago
    There's plenty of ways to securely multiplex Ethernet devices. You don't give your web server read access to all TCP ports being used by other services for example. You only let it open the HTTP ports. There are of course ways for debuggers to escape this and intercept all TCP packets sent by the kernel, but those require elevated privileges.
  - kaba0 5y ago
    Sway is in top-up form and is basically just i3 on wayland. Even the config is largely compatible, so do give it a try, if you haven’t (recently)!
    - zaat 5y ago
      I tried it not long ago. It's ok, took me some time to overcome some issues but got it to work, then, when I started actually working I met the same issues regarding screenshots, remote control/screen sharing and decided to stay with i3 while I can.

craftinator 5y ago

So I can't log my own keystrokes on Wayland? Anti feature.

taway098123 5y ago
If you have root access to your own system, or read access to /dev/input, then it's trivial to deploy a keylogger. No need for Wayland to get involved there. You can't log keys through the Wayland socket because that socket is intended to be accessible to sandboxed programs.
- michaelmrose 5y ago
  So to be clear you want such a program to be implemented to be running as root in a way that the user can't individually control its just another root daemon that the user may or may not be aware of.
  - taway098123 5y ago
    That's one way to do it, it's probably not the best way but it would work if you were planning to sidestep Wayland security completely. You could make it user controllable with dbus and then make a GUI to talk to it.
  - kaba0 5y ago
    craftinator wanted a way to log his/her own keyboard events. Of course a custom extension can also be created for this use-case, in which way the compositor can allow/deny access for keypresses to specific windows. But to be honest a central hot-key manager where apps can register new bindings (and with compositor managed multiple bindings resolution instead of the ad hoc way under X) would be a great target.

CarelessExpert 5y ago

I've heard all the excuses. None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases, or worse, to make those use cases someone else's problem (e.g. screen sharing), thereby creating fragmentation in the ecosystem due to a lack of standardization. After all, it's pretty rich to blame Gnome or KDE for "[deciding] to do something different" when Wayland was very deliberately designed to offer no standard for how to do the thing in the first place. I'd actually prefer it was unintentional, as that would imply simple oversight. If it was intentional, that implies deliberately bad design choices that have gotten us to the semi-broken place we are right now; a place we're only finally getting out of as other people (e.g. the PipeWire folks) step in to cover up the spike-filled holes that Wayland has left behind.

taway098123 5y ago
These aren't excuses, there are no other parties at play here. Weston was the first implementation. GNOME and KDE were the next implementations. They could have chosen to copy Weston's implementation, thus making those parts "standard" but they didn't. That's the way it played out. The way you're talking about it makes it sound like there was some outside force designing Wayland and convincing the other designers to exclude screen sharing, when it wasn't like that at all. You also seem to be suggesting that they could have designed everything in hindsight perfectly before the implementations even existed, I hope I don't need to point out why it doesn't work like that. You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.
- CarelessExpert 5y ago
  > You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. Given that Wayland was first released in 2008 and the first commit to the PipeWire project was in 2015, I'm quite confident at this point that you're rewriting history to support your position.

pantalaimon 5y ago

> Maybe someone will figure out a good way to do this but I wouldn't hold my breath. Android and iOS and Browsers these days already have figured out something for those kind of things - they ask for permission.

taway098123 5y ago
The usual place those permission dialogs have gone is the flatpak portal, which is separate from Wayland. Someone would have to implement it there.

destructionator 5y ago

> Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers https://www.x.org/wiki/Development/Documentation/Security/ https://www.x.org/wiki/Development/Documentation/Security/ The X.Org Foundation released 7.2.0 (aka X11R7.2) on February 15th, 2007. The Wayland devs themselves say "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X." https://wayland.freedesktop.org/faq.html#heading_toc_j_5 https://wayland.freedesktop.org/faq.html#heading_toc_j_5 They just didn't want to.

the_why_of_y 5y ago
XACE is basically an extension of SELinux into userspace for X11. Given that today Fedora/RHEL are the only distros that enable SELinux out of the box, such an approach would have been doomed to failure (or doomed to provide a product differentiator for RHEL in the best case) - not to mention the sheer joy and excitement that debugging SELinux AVC denials would produce for end users and desktop application developers. https://www.freedesktop.org/software/XDevConf/x-security-walsh.pdf https://www.freedesktop.org/software/XDevConf/x-security-wal... (Wayland's "buffer exchange and update models" won't provide security on their own without any improvement on the input side)