4 ms·

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

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.

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.