3 ms·

I had understood that this was also true under ~MacOS and~ Windows. Keylogging and screen monitoring is trivial in Windows. Wayland solves a problem that is p

I had understood that this was also true under ~MacOS and~ Windows. Keylogging and screen monitoring is trivial in Windows. Wayland solves a problem that is present on all systems, but it does it with a sledgehammer. [Edit] I am reminded that MacOS has a sane model for this.

MBCook 4y ago
MacOS does not allow screen sharing (say in Google Chat) of your entire desktop or other windows without user permission. The application has to be added to a list of allowed applications through the System Preferences. Same with intercepting all keyboard input IIRC. Can’t speak to Windows.
- happymellon 4y ago
  You are correct, I remember now. Although this wasn't always the case, it has been true for a few years now.
  - MBCook 4y ago
    Yeah. Two or three releases I think.
pcwalton 4y ago
macOS has a reasonable security model and it doesn't allow that without explicit (annoying-to-grant) user consent. On Windows, apps that are concerned about RCE can drop privileges and still access the desktop in a secure way. On X11, there is no such option; you have to adopt a Chromium-like content/chrome process model, with the content process having no windowing access whatsoever. Because it's so difficult, almost nobody does this on X11.
- happymellon 4y ago
  Ah, yes you are correct! I do remember the Mac security model, and I think it is a much better solution to Wayland. Don't ban, just make it a user specific choice.
  - pcwalton 4y ago
    I can't imagine anyone involved with Wayland wants to ban screen recorders. They just want to make sure they get the security right.
    - happymellon 4y ago
      But they did, and there are requests that they provide a standardised API for screensharing/recording which are `wontfix`. All the desktops made their own API outside of Wayland and Pipewire standardised a global API wrapper for everyone's implementation. Whether that's the correct location rather than Wayland is a separate discussion.
      - kaba0 4y ago
        But then you are just claiming inconsistent things. Also, screen sharing is indeed a different problem as that often mandates sound recording/transmission as well which is very much not in scope for a display manager. (That’s where we can see how a cathedral model could fare better). I think having a simple screen shot api in wayland is a good idea, while letting pipewire properly solve video (and optionally audio) channeling a good technical solution.
        happymellon 4y ago
        Nothing I have said is inconsistent, and I haven't said that the resulting implementation is bad although I disagree it's outside the realm of a display manager whan all of them had to implement an API to get it to work. The only thing I have said is that Wayland has not, and will not implement an API to their specification. Everyone has implemented their own one due to the lack of directionn and then Pipewire did the presentation API. It could have been a lot tidier if Wayland had actually accepted that they are the display server and that Pipewire will want an API to capture the display. Pipewire is the correct output as it captures both audio and visual and can do manipulation of the output as required, but the display server feeds the visual output.
vetinari 4y ago
MacOS and Windows never gave direct socket and well-defined protocol to the display server. If you wanted to connect, you had to use their client libs. Turns out, you can handle many cases in the linked libraries and if you do not have them, and you cannot change the protocol, touch luck. Sledgehammer time.

MBCook 4y ago

MacOS does not allow screen sharing (say in Google Chat) of your entire desktop or other windows without user permission. The application has to be added to a list of allowed applications through the System Preferences. Same with intercepting all keyboard input IIRC. Can’t speak to Windows.

happymellon 4y ago
You are correct, I remember now. Although this wasn't always the case, it has been true for a few years now.
- MBCook 4y ago
  Yeah. Two or three releases I think.

pcwalton 4y ago

macOS has a reasonable security model and it doesn't allow that without explicit (annoying-to-grant) user consent. On Windows, apps that are concerned about RCE can drop privileges and still access the desktop in a secure way. On X11, there is no such option; you have to adopt a Chromium-like content/chrome process model, with the content process having no windowing access whatsoever. Because it's so difficult, almost nobody does this on X11.

happymellon 4y ago
Ah, yes you are correct! I do remember the Mac security model, and I think it is a much better solution to Wayland. Don't ban, just make it a user specific choice.
- pcwalton 4y ago
  I can't imagine anyone involved with Wayland wants to ban screen recorders. They just want to make sure they get the security right.
  - happymellon 4y ago
    But they did, and there are requests that they provide a standardised API for screensharing/recording which are `wontfix`. All the desktops made their own API outside of Wayland and Pipewire standardised a global API wrapper for everyone's implementation. Whether that's the correct location rather than Wayland is a separate discussion.
    - kaba0 4y ago
      But then you are just claiming inconsistent things. Also, screen sharing is indeed a different problem as that often mandates sound recording/transmission as well which is very much not in scope for a display manager. (That’s where we can see how a cathedral model could fare better). I think having a simple screen shot api in wayland is a good idea, while letting pipewire properly solve video (and optionally audio) channeling a good technical solution.
      - happymellon 4y ago
        Nothing I have said is inconsistent, and I haven't said that the resulting implementation is bad although I disagree it's outside the realm of a display manager whan all of them had to implement an API to get it to work. The only thing I have said is that Wayland has not, and will not implement an API to their specification. Everyone has implemented their own one due to the lack of directionn and then Pipewire did the presentation API. It could have been a lot tidier if Wayland had actually accepted that they are the display server and that Pipewire will want an API to capture the display. Pipewire is the correct output as it captures both audio and visual and can do manipulation of the output as required, but the display server feeds the visual output.

vetinari 4y ago

MacOS and Windows never gave direct socket and well-defined protocol to the display server. If you wanted to connect, you had to use their client libs. Turns out, you can handle many cases in the linked libraries and if you do not have them, and you cannot change the protocol, touch luck. Sledgehammer time.