You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While this might sound counterintuitive at first, without any checking from the portal about what is calling it when requested to take a non-interactive screenshots would allow an attacker to capture the screen without the user's explicit consent. Gnome gets around this issue by directly baking the screenshot utility into the compositor (which it considers privileged), and always prompts otherwise. Plasma has an open issue for this here: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/7
From that issue:
Proposed Solution
For the first non-interactive screenshot request per application, display a confirmation dialog with the following options, asking the user:
Application [APP_NAME] wants to take a screenshot
Allow temporarily (allows the app to take a screenshot this one time, will ask for confirmation again if it wants to take another)
Allow permanently (allows the app to take a screenshot this time, as well as allow all future requests* non-interactively)
Deny (denies the app to take a screenshot this time, as well as all future requests* non-interactively)
Question: What do we mean by "all future requests"? Answer: One of the following:
All future requests in this session, i.e. preferences reset after PC restart or log in -> log out
All future requests until the end of time, i.e. preferences are saved in a config file. NOTE: With this approach we must keep in mind that certain applications could potentially write to config files and give themselves permission!
Regarding "one of the following", it should be noted that for All future requests until the end of time, i.e. preferences are saved in a config file. NOTE: With this approach we must keep in mind that certain applications could potentially write to config files and give themselves permission! something along the lines of polkit could possibly used to store such data in root writeable only directory?
While this isn't an immediate concern, it is probably worth coming up with a strategy for how to handle this for the future.
This can be tested by using a 3rd party screenshot tool (such as flameshot) to capture the screen, and it successfully does so without a prompt.
The text was updated successfully, but these errors were encountered:
While this might sound counterintuitive at first, without any checking from the portal about what is calling it when requested to take a non-interactive screenshots would allow an attacker to capture the screen without the user's explicit consent. Gnome gets around this issue by directly baking the screenshot utility into the compositor (which it considers privileged), and always prompts otherwise. Plasma has an open issue for this here: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/7
From that issue:
Regarding "one of the following", it should be noted that for
All future requests until the end of time, i.e. preferences are saved in a config file. NOTE: With this approach we must keep in mind that certain applications could potentially write to config files and give themselves permission!
something along the lines of polkit could possibly used to store such data in root writeable only directory?While this isn't an immediate concern, it is probably worth coming up with a strategy for how to handle this for the future.
This can be tested by using a 3rd party screenshot tool (such as flameshot) to capture the screen, and it successfully does so without a prompt.
The text was updated successfully, but these errors were encountered: