4 ms·

Sure, but there are also legitimate uses for things like that, otherwise people wouldn't want them. How you build screen-recorders for example without "grabbing

Sure, but there are also legitimate uses for things like that, otherwise people wouldn't want them. How you build screen-recorders for example without "grabbing pixels that aren't yours"? Clearly, something is missing here. Why not a permission system like browsers do? A little popup that asks "X is requesting access to your full screen" rather than this "convenience VS security" black and white view most people seem to take a stance at?

Gigachad 3y ago
The answer is that these need to be special privileges controlled by the OS. Which is exactly how wayland manages it. Discord capturing the screen is a valid use case, but it should be approved by the DE and it should be possible to block this request. Currently the mainstream DEs just approve the request by default but in the future I can see a permissions dialog asking the user if they want to allow access to screen recording, and maybe a small icon in the top bar to show when recordings are happening.
- Bu9818 3y ago
  Yup, or with your own scripts managing bwrap and security-context if not using a DE/Flatpak.
- roenxi 3y ago
  That answer sucks so much that after nearly 15 years of Wayland evangelism KDE e.V. Directors are writing blog posts with "Wait, that sounds like it sucks" as a heading and talking about how the issues have been resolved to the point where it is just "ready enough for Plasma and KDE apps", with some reasonable paraphrasing. That is not a history to be proud of, for all that even Wayland is a big step up from X and we're all grateful for the efforts these people go to. This idea that screenshots require special OS-level privileges has been tested and, in practice, does not work. Literally nobody wants compositor-specific screenshot applications. It should have been addressed in the Wayland standards in the early drafts. Fair enough unrestricted access to any pixel is a security problem. But banning all access to pixels other programs control was an unworkable position that, in hindsight, didn't work. Telling people that the process that merges all the pixels together needs special OS-level support for reporting on what the merged output look like is just not sane. Something went wrong in the design process.
  - phkahler 3y ago
    This discussion IMHO shows why it's been so contentious. Wayland started from the secure end without having answers to questions like screen grabbing/sharing or GIMP eye dropper. They figured there would be solutions down the road. On the other side a bunch of people complained about shortcomings like these, but rather than offer solutions they just wanted to stick with X. IMHO the right answer might be a GUI toolkit (out of process) that has an API for system resources. Permission would be either granted by the user (a file dialog already indicates what files an app should have access to) or set at the application level at install time. The failure to develop solutions like this is why browsers have taken it on by themselves, because they are constantly running untrusted code.
    - roenxi 3y ago
      The right answer is this repository: https://gitlab.freedesktop.org/wayland/wayland-protocols https://gitlab.freedesktop.org/wayland/wayland-protocols They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful. You can see the docs in pretty form here: https://wayland.app/protocols/ https://wayland.app/protocols/ Only took 15 years. Pay special attention to the name of Drew DeVault who has been one of the major heros in the story. The Wayland devs apart from Drew do deserve serious kudos, moving away from X was never going to be easy. But copying pixels into a shared buffer as some sort of challenge is just hard to overlook.
      - phkahler 3y ago
        >>They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful. Dude please. Wayland has been 100 percent usable FOR ME for years. Plain Wayland is not "crippled" for MY use case. It may be crippled for YOUR use case, and that's a legitimate concern, but don't broad brush Wayland as not usable and crippled in general. For many of us it's already where it needs to be. That said, I do hope those remaining things get sorted out soon.
brennoflavio 3y ago
But this happens with Wayland nowadays (at least on Gnome). When you try to take a screenshot or share your screen, a popup appears where you can select the monitor, area, window, etc, before sending the image to the software. If you close the screen, the software fails. Try to use Flameshot or Google meet on Ubuntu to see that behavior.
- phkahler 3y ago
  Screenshots work fine for me on Fedora Wayland. Just like you say, except for the failing.

Gigachad 3y ago

The answer is that these need to be special privileges controlled by the OS. Which is exactly how wayland manages it. Discord capturing the screen is a valid use case, but it should be approved by the DE and it should be possible to block this request. Currently the mainstream DEs just approve the request by default but in the future I can see a permissions dialog asking the user if they want to allow access to screen recording, and maybe a small icon in the top bar to show when recordings are happening.

Bu9818 3y ago
Yup, or with your own scripts managing bwrap and security-context if not using a DE/Flatpak.
roenxi 3y ago
That answer sucks so much that after nearly 15 years of Wayland evangelism KDE e.V. Directors are writing blog posts with "Wait, that sounds like it sucks" as a heading and talking about how the issues have been resolved to the point where it is just "ready enough for Plasma and KDE apps", with some reasonable paraphrasing. That is not a history to be proud of, for all that even Wayland is a big step up from X and we're all grateful for the efforts these people go to. This idea that screenshots require special OS-level privileges has been tested and, in practice, does not work. Literally nobody wants compositor-specific screenshot applications. It should have been addressed in the Wayland standards in the early drafts. Fair enough unrestricted access to any pixel is a security problem. But banning all access to pixels other programs control was an unworkable position that, in hindsight, didn't work. Telling people that the process that merges all the pixels together needs special OS-level support for reporting on what the merged output look like is just not sane. Something went wrong in the design process.
- phkahler 3y ago
  This discussion IMHO shows why it's been so contentious. Wayland started from the secure end without having answers to questions like screen grabbing/sharing or GIMP eye dropper. They figured there would be solutions down the road. On the other side a bunch of people complained about shortcomings like these, but rather than offer solutions they just wanted to stick with X. IMHO the right answer might be a GUI toolkit (out of process) that has an API for system resources. Permission would be either granted by the user (a file dialog already indicates what files an app should have access to) or set at the application level at install time. The failure to develop solutions like this is why browsers have taken it on by themselves, because they are constantly running untrusted code.
  - roenxi 3y ago
    The right answer is this repository: https://gitlab.freedesktop.org/wayland/wayland-protocols https://gitlab.freedesktop.org/wayland/wayland-protocols They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful. You can see the docs in pretty form here: https://wayland.app/protocols/ https://wayland.app/protocols/ Only took 15 years. Pay special attention to the name of Drew DeVault who has been one of the major heros in the story. The Wayland devs apart from Drew do deserve serious kudos, moving away from X was never going to be easy. But copying pixels into a shared buffer as some sort of challenge is just hard to overlook.
    - phkahler 3y ago
      >>They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful. Dude please. Wayland has been 100 percent usable FOR ME for years. Plain Wayland is not "crippled" for MY use case. It may be crippled for YOUR use case, and that's a legitimate concern, but don't broad brush Wayland as not usable and crippled in general. For many of us it's already where it needs to be. That said, I do hope those remaining things get sorted out soon.

brennoflavio 3y ago

But this happens with Wayland nowadays (at least on Gnome). When you try to take a screenshot or share your screen, a popup appears where you can select the monitor, area, window, etc, before sending the image to the software. If you close the screen, the software fails. Try to use Flameshot or Google meet on Ubuntu to see that behavior.

phkahler 3y ago
Screenshots work fine for me on Fedora Wayland. Just like you say, except for the failing.