When a screenshot is taken in the gnome extension via the captureScreenshot function, a window pops up and the typical sound of taking a photo is played.
extension.js:
import {Extension} from 'resource:///org/gnome/shell/extensions/extension.js';
import * as Screenshot from 'resource:///org/gnome/shell/ui/screenshot.js';
import Shell from 'gi://Shell';
export default class ExampleExtension extends Extension {
async enable() {
const shooter = new Shell.Screenshot();
const [content] = await shooter.screenshot_stage_to_content();
const texture = content.get_texture();
await Screenshot.captureScreenshot(texture, null, 1, null);
}
disable() {
}
}
You have been asking this stuff for a while, now, and you have explained very little about what you want to achieve.
Random applications taking screenshots of the contents of the screen without the user getting any feedback is a quite scary security violation, so it’s unsurprising that the OS is fighting back against it.
Why are you taking screenshot? Why are you trying to associate them with the currently focused applixarion? What kind of application and scenario are you actually implementing?
There is an application that records user activity in the current session, including screenshots. And it should do it quietly, that is, no pop-ups, etc.
on x11 everything works without problems, but on wayland it doesn’t, so I’m trying to transfer this functionality to the gnome extension @ebassi
There are privacy issues in X11 that allow this kind of ugly things to work.
Wayland architecture is much better in terms of user privacy, and such spywares should not work anymore, as per design. So the behavior you described is expected.
If there was a way to circumvent this, then that would be a bug.
But shouldn’t privileged components (like the gnome extension) have the rights to do this? This is not a random application, but part of the gnome shell, if I understand correctly
Is there anyway to disable these notifications? Hearing the characteristic sound of a screenshot every time will be annoying @gwillems
What gave you that impression? Under GNOME 46, in a Wayland session, any capture triggered by gnome-screenshot will always be accompanied by the screenshot audio/visual effect.
X.org is fundamentally insecure in ways that can’t be corrected, so it’s impossible to prevent potentially invasive actions like stealth captures of the screen contents. That’s why Wayland was created (not the whole reason but one of the motivating factors), to replace insecure X.org sessions with ones that don’t hemorrhage sensitive personal information like the contents of your screen at any random moment some software might choose to spy on you.
But under Wayland, by design, such actions require user approval and/or notification. No matter where they originate.
Extensions are not privileged, and they’re precisely the opposite of “part of the Shell” — they’re untrusted1 third-party-code. (It’s not expected that they’d be malicious code, at least if the extension is reviewed and published on extensions.gnome.org2, but they’re still external code being granted access to the Shell runtime.)
The extent to which Extensions are able to access private Shell internals is viewed as a pragmatic compromise / necessary evil, not a granting of elevated privileges. Extensions have the minimum level of access to protected APIs that it’s practical to give them without crippling their functionality. Which means it’s unavoidably pretty substantial (and far greater than ideal), but far less than system internals.
Notes
Well… in an ideal world they’d be treated as untrusted, and perhaps even confined to isolated sandboxes for safety. But the Shell doesn’t have a compartmentalized runtime, and the whole Extensions model is predicated on them being able to (gently!) poke at the Shell’s squishy innards, so the practical reality is that they’re treated closer to “semi-trusted”. But definitely not “equivalent to built-in system components” levels of privileged! That’s just an incorrect model of the extension system as a whole.
A review process I’d hope would reject any extension implementing silent screenshot captures, even if you did find an exploitable bug that made such a thing possible. IMHO that’s malware, plain and simple, unless you can show how it’s not compromising the user’s privacy. (And some type of “In our use case the user has no expectation of privacy” corporate handwave doesn’t count. It’s fine to operate under that model. And it’s equally fine for the system to have no support for it, anywhere up and down the stack, unless you write it yourself. The entire system is open-source, after all.)
You are right that extensions are third-party code that you shouldn’t trust blindly, but they absolutely are privileged.
Extensions are a mechanism to load external code into gnome-shell. Once an extension has been enabled, it is impossible to tell if some specific compositor state is the result of “regular” code, an extension or a mix of both.
In particular, extensions don’t exist as distinguishable entities that are executed by the shell process, they modify the running gnome-shell process itself. Because of that, I also like to call them “live patches to the compositor”.
And as enabled extensions aren’t separate from the compositor process they modify, they aren’t any less privileged than the compositor itself. Which is about as privileged as a user process can be
