Screenshot portal without prompt

[lionirdeadman]

This may seem dangerous but for screenshot applications, this sounds necessary from a design POV. Having a screenshot application which asks twice to screenshot would be quite awkward, I think.

Related : https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970 , flameshot-org/flameshot#1910

[smcv]

Is your request something like this?

• Invent some special metadata that can be set on a Flatpak (or Snap?) app, with the semantics "this app can take screenshots without prompting". Flatpak (and Snap?) would not do anything differently in setting up sandboxes based on this metadata, it's just a marker.
• Make the screenshot portal look for that metadata in /.flatpak-info. If it's present, just take the screenshot without prompting, with parameters (window/whole screen/etc.) controlled by the request.
• Maybe the portal backend is still responsible for visual/audio feedback (screen flash/shutter sound) to make sure the user is aware that a screenshot was taken?
• Ideally, app stores like Flathub limit access to that metadata (more review required), in the same way they ideally would for other "dangerous" permissions like host filesystem access.

Or a possible alternative would be to do something a bit like #638:

• Have a flag that the screenshot app can set, to say "I'm always going to need this permission"
• The first time that flag is used, have a prompt with some sort of "remember this" option
• Make a note in the permission store that this app is OK to take screenshots any time, or give it a token that can be looked up in the permission store later, or similar

Or a mixture of the two: ignore or reject the flag from the second approach if it's set by an app that doesn't have the permission metadata from the first?

[lionirdeadman]

I think it should be strictly easy to control so it shouldn't be metadata (and require something like Flatseal to change).

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

[borgmanJeremy]

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

This is my proposal as well, similar to permissions on a mobile OS.

(I am the maintainer for the screenshot program Flameshot)

[DamirPorobic]

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

Agree with this one. The user experience with pop up dialogs that require additional clicks every time you take a screenshot is just not a way to go.

I'm the developer and maintainer of ksnip.

[mcatanzaro]

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

Giving the user the option to grant the application permission to take future screenshots/screencasts without further user permission would be OK. We just don't want the application to be able to give itself this permission, or to be able to force the user to grant this permission in order to use it just once.

So let's forget about additional metadata. I would retitle this issue from "Screenshot portal without prompt" to "Screenshot portal should have toggle for user to disable future prompts for this application."

[DamirPorobic]

As part of such change it would be useful to pass the type of screenshot that should be taken. The prompt that opens up is not just a permission thing but also a selection of type of screenshot (and if the cursor should be included eventually).
If the user for example first asks for Active Window screenshot and confirms that he don't want to be asked again, what happens when the user requests another screenshot and expects to get a fullscreen screenshot now. Currently there is just an option to ask for scrrenshot but not what kind of screenshot.

[mcatanzaro]

OK, makes sense. So: add API for application to choose the type of screenshot that should be taken, only show the option to permanently grant permission to take screenshots if the new API is used.

That wouldn't apply the same to screencasts, but those are a separate portal.

[DamirPorobic]

Yeah, I think just a dialog that asks for that permissions with an option to make it permanent would in that case be the best, without any other selection option. Bonus points for additional parameter in the API call like "Include cursor" and "Include window decoration".

That wouldn't apply the same to screencasts, but those are a separate portal.

Yes, I think it was a different API but I can imagine that they have similar issues if they haven't been fixed already.

[Midnex]

I hope you only have to give permission one time, and then from there it can do it every time. This would be more secure than the old method, but less annoying then the current.

[kurobeats]

Can I express how powerless this issue makes me feel in relation to Gnome development. The tone from the Gnome folks here: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970 indicates to me this issue will not be resolved/is not considered an issue. Creating a Gnome related bug report is akin to shouting into the void, isn't it?

[DamirPorobic]

They don't see the issue there but it's probably the same folks that doesn't take much screenshots so they don't feel the pain. As long as they're not made aware about the user frustration coming from this, they won't fix it I'm afraid.

[mcatanzaro]

Can I express how powerless this issue makes me feel in relation to Gnome development. The tone from the Gnome folks here: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970 indicates to me this issue will not be resolved/is not considered an issue. Creating a Gnome related bug report is akin to shouting into the void, isn't it?

Honestly, your expectations are misplaced. Bypassing the screenshot portal is unacceptable, as it defeats the point of having the portal in the first place. Applications should not be able to screenshot your desktop without your permission. Removing the backdoor should not be controversial.

If you read up in this issue, we already have agreement on the path forward to enhance the screenshot portal. It's just waiting for a motivated developer to tackle it.

[VitalyAnkh]

@kurobeats @DamirPorobic
The Gnome developers made this decision (don't allow external apps to use gnome's private API) for protecting the privacy of users and forbidding API abuse. They are also doing a redesign for the screenshot UI of gnome: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954

The Words accusing the developers of not caring about something are not true, and totally unconstructive.

[DamirPorobic]

@VitalyAnkh I've spoken with Gnome developers (also same with KDE developers but they haven't disabled the private dbus yet) on few occasions about this topic, on tickets and on IRC and my impression was that this is for them a minor inconvenience. One of them told me even that this is a fair trad off, few clicks more but you get more security. So I don't see it as "not true" and even the "totally unconstructive" is debatable, user requirement sets the prio for features, if no one speaks up the developers that don't use this feature won't get the user pain.

Not sure what the screenshot UI redesign to do with this issue, our problem is that we need to give permission for every screenshot instead of once like most people are used to like from mobile phone apps.

@mcatanzaro is right, there is a suggestions that, when implemented, would fix our issues, I don't see any further discussion here.

[kurobeats]

Honestly, your expectations are misplaced.

Maybe so but the action taken has now created a negative user experience. Forgetting my comments, I'm a voice in the crowd, think about the "regular user", they are going to see this behaviour and be confused by it because it's not something they have come to expect.

Bypassing the screenshot portal is unacceptable, as it defeats the point of having the portal in the first place. Applications should not be able to screenshot your desktop without your permission. Removing the backdoor should not be controversial.

Let's keep in mind we are talking about a screenshotting tool here not a trojan (which I imagine we are trying to defend against here). Flameshot, for example, doesn't have to overcome hurdles to screenshot on Windows or MacOS.

If you read up in this issue, we already have agreement on the path forward to enhance the screenshot portal. It's just waiting for a motivated developer to tackle it.

I'm very happy to hear it, but wouldn't it have been pragmatic to implement the solution before we do unexpected things to the user base?

[borgmanJeremy]

Author of flameshot here, actually on MacOS you do have to grant a one time permission to record the the screen.

While I was annoyed this changed in gnome before we adjust the portal to only ask a single time, overall this will be a great compromise between ease of use and security. It also will be exactly the same as MacOS. I think my users will also find the one time prompt acceptable.

[Remzi1993]

Yeah, I think just a dialog that asks for that permissions with an option to make it permanent would in that case be the best, without any other selection option. Bonus points for additional parameter in the API call like "Include cursor" and "Include window decoration".

That wouldn't apply the same to screencasts, but those are a separate portal.

Yes, I think it was a different API but I can imagine that they have similar issues if they haven't been fixed already.

Yeah I fully agree!!
I understand the security concerns from the Gnome team, but it's also about giving users options. Give users the ability to give certain applications permission to do this and remember their choice.

Certain programs like Screenshot apps and screen capture/recording programs need this to work. And giving those programs permission every time gets tiring and not user friendly. (from an UX point of view)

[dancojocaru2000]

I'm rather amazed that people invoke "security" as a reason while undermining security by not thinking things through.

When a security feature is very annoying or even breaks software, it becomes an anti-feature. For example, when Telegram Desktop was failing to read files I was drag and dropping into it because the portal wasn't smart enough to see that drag and drop should give permissions for that file, I installed Flatseal and gave Telegram Desktop permissions to all files. Where's the security in that?

Any security features that are sufficiently irritating become just yet another annoying thing to turn off. They not only provide zero security, but are also an added annoyance.

While I appreciate the concern and I also appreciate that a decision was reached to implement the "remember this obvious choice" feature, I am disappointed that usability and actual security are not priorities and they are just an afterthought after users complain.

I would hope this is implemented and more care is taken in the future when "security" features are implemented, because for now I've gotten used to avoid Flatpaks in order to have actually functioning applications, and I'd love for that to change in the future.

[jf2048]

@dancojocaru2000 IIRC that is not related to a security feature, it's missing functionality in the application and it needs to add support for the file transfer portal. Please follow the discussion here: #99

Edit: According to this issue the missing functionality was in Electron: https://github.com/flathub/org.telegram.desktop/issues/23

[kurobeats]

Hi Team,
Can I request if this issue is being addressed? Totally fine if it isn't deemed an issue, I can revert to Xorg.

[All3xJ]

Any news? This is not normal. Workflow can't be damaged this way..

[angordeyev]

Very frustrating, please give a user an option not to see the window every time, the great thing about Linux is flexibility and I would not like to see it less flexible than e.g. macOS.

[All3xJ]

I reported again to gnome upstream: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970#note_1341047
and here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4895

[michael-hart-github]

Edit: I understand what was meant in the comments above now. (Stupid me!) The fix for this has already been processed and was pushed through GNOME 43. You can find out which version of GNOME you're using with gnome-shell --version. BTW, if you are running Fedora, it will be available with Fedora 37, release date is quoted "around 25 OCT 2022".

@jadahl If you happen to have info on where/how we can set this, please reply. I have run into this issue recently as well, and had initially assumed there was an issue with flameshot, since I had never used it before. Realizing that this is a permissions thing, that I need to permit each time I launch the program, is getting very tedious to deal with even if the program itself is considerably better than the default screenshot program.

@axel-n How did you go about getting all of those permissions listed in Settings? My own listing looks like this

[kon14]

@axel-n How did you go about getting all of those permissions listed in Settings? My own listing looks like this

@michael-hart-github
That's Flatseal, not Gnome Settings.

[andreyizrailev]

I'm sorry if I missed something, but I wasn't able to find any guidence on how to update xdg-desktop-portal in order for gnome not to ask if I want to share my screenshot with Flameshot every time. Could you please point me to how I can do this? I'm using ubuntu 22.04 with gnome 42.

[gpothier]

@andreyizrailev I think the easiest solution would be for you to upgrade to 22.10, which has this feature out of the box. And the new Gnome in that version is quite nice too, so I'd say it's worth the upgrade.

[andreyizrailev]

@gpothier that is very unfortunate that I have to choose between the long term support and a convenient way of making screenshots. But thank you for the answer!

[jadahl]

btw, how fast is the portal api? Can it do 30+FPS?

You shouldn't use the screenshot portal to make screencasts, there is the screenast portal for that.

[rainisto]

btw, how fast is the portal api? Can it do 30+FPS?

You shouldn't use the screenshot portal to make screencasts, there is the screenast portal for that.

I'm currently capturing bbox regions from 4k desktop (for performance reasons). Is screencast portal able to provide casts from partial desktop regions? Have to start searching for API documentation. Does screencast portal api have setting for not asking end user permissions (as target machine is running in kiosk mode without keyboard and mouse).

[jadahl]

Is screencast portal able to provide casts from partial desktop regions?

No, but can in theory be added.

Does screencast portal api have setting for not asking end user permissions

Yes.

[All3xJ]

Thanks a lot, devs! :D expecially @GeorgesStavracas

[Pheggas]

Why is this closed? The issue is still there.

[mcatanzaro]

This issue was fixed by c827417.

[ZaneBartlett1]

For people who are a bit newer to Linux -

Note that Ubuntu releases are the year and date, so Ubuntu 22.04 was released 2022 on the 4th month.

Ubuntu 22.04 LTS comes with GNOME 42.5 (you can verify this yourself by running gnome-shell --version), and it's extremely unlikely to receive an official update to GNOME 43. LTS releases happen every two years, so the next one will be Ubuntu 24.04 LTS, which will include GNOME 43 or a newer version. So right now, for Ubuntu LTS you can expect this to be fixed in about a year from this posting, in 2024 on the 4th month.

If you want GNOME 43 sooner, you can upgrade to Ubuntu 22.10 now or newer versions when they're released. None of these will be considered LTS releases though and non-LTS releases have a shorter support period of 9 months. This means you'll need to upgrade more frequently to stay on a supported version.

Another option is to install GNOME 43 from a third-party repository (like a PPA) or build it from source. This method can be risky, as it might cause compatibility issues or system instability. If you choose to try to do this, you should really consider backing up your data and be ready to troubleshoot potential issues. Although, if you had to read this to understand the situation, I don't really suggest this option.

[lxwulf]

Sorry to bother you, but I don't get why it doesn't work on my Fedora 39 system… This should have the fix not true? I still can take screenshots with flameshot… 🤷‍♂️ 😵‍💫

I appreciate every help or direction to the possible solution.

[ZaneBartlett1]

@lxwulf, I don't know how you check the version of GNOME on fedora. A quick search shows that it should, but you can, and need to, directly confirm your GNOME version. If you can confirm that you're on GNOME 43+ and that there's no other changes that have been made that would cause any issues (searching error messages if you're getting them + GNOME version) then I would imagine you could treat it as a bug. I would open a new issue.

And just to be clear, you're having an issue were on Fedora 39, if you take a screenshot with flameshot, you're still being prompted on every screenshot to pass it to another program? If that's the case, then I stand by what I say above, otherwise, you may need to clarify

[whot]

I don't know how you check the version of GNOME on fedora.

fwiw, it's slightly hidden in GNOME Settings -> About -> System Details. That should work regardless of distro. Fedora is on GNOME 45.x.

[adangel]

@lxwulf See flameshot-org/flameshot#2868 - it seems, there is an issue on how flameshot is started. E.g. for me it doesn't work, if flameshot is started automatically/from the app menu. If I stop it and start it manually from a terminal, it works.

[lxwulf]

@ZaneBartlett1:

As @whot mentioned, I'm on GNOME 45.5. It does work if I manually start flameshot from the terminal but not if it's in autostart as @adangel already mentioned. This applies for the rpm package, the flatpak version doesn't work in any case.

@adangel:

Yes, I saw this issue and also already commented. Anyway, they say the problem relies on the xdg-desktop-portal not on the application itself. Which it shouldn't at least not on my system because it's updated to the newest version. Do I miss a package or a setting? Is Wayland perhaps an issue?

[mcatanzaro]

You probably want to create a new issue report at this point, since this one is closed.

[cippo1987]

This exemplify well why people do not join linux. The total disrespect and paternalism of some dev towards users.

[acosonic]

Please reopen and fix the issue...

[mcatanzaro]

This issue was fixed by c827417.

This issue was fixed two years ago. Whatever problem you're having is not this issue. Feel free to report a new issue.

[mcatanzaro]

Actually, please make sure your portal backend has an access portal implementation before reporting a bug here, because the screenshot portal will always prompt you for permission if you don't have an access portal implementation. If you don't have an access portal implementation, you can report the issue to your portal backend instead. I see xdg-desktop-portal-gnome, xdg-desktop-portal-gtk, and xdg-desktop-portal-kde all have access portal implementations. But notably, xdg-desktop-portal-xapp does not. (xdg-desktop-portal-wlroots doesn't either, but that one is clearly intended to be used in combination with a more featureful portal backend, so that's probably OK.)