# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 10
# self = https://watcher.sour.is/conv/spekvyq
I’m a bit confused here. One of Wayland’s advantages is to isolate clients better. For example, on X11, any client can read the screen and, thus, possibly sensitive data. That really isn’t too great.
But one valid use case of this X11 “feature” is to make screenshots.
To make screenshots work on Wayland, this protocol exists:
https://wayland.app/protocols/wlr-screencopy-unstable-v1
What I would have expected is that, when I run a screenshot tool (e.g., grim), the compositor asks me: “Hey, that program wants to make a screenshot, is that OK?” (That might be a bit annoying, but it’s the only way I can think of to avoid programs silently taking screenshots in the background.)
What happens instead is that grim just makes a screenshot, just like on X11.
I searched the bug trackers of some compositors (labwc, sway, hyperland), but couldn’t find any discussions about this.
Aren’t we almost back to square one now … ? The only advantage is that compositors now *could* ask, because there’s a well-defined protocol. But in practice they don’t. Hm.
cc @mckinley since you seem to have some more experience with Wayland.
I’m a bit confused here. One of Wayland’s advantages is to isolate clients better. For example, on X11, any client can read the screen and, thus, possibly sensitive data. That really isn’t too great.
But one valid use case of this X11 “feature” is to make screenshots.
To make screenshots work on Wayland, this protocol exists:
https://wayland.app/protocols/wlr-screencopy-unstable-v1
What I would have expected is that, when I run a screenshot tool (e.g., grim), the compositor asks me: “Hey, that program wants to make a screenshot, is that OK?” (That might be a bit annoying, but it’s the only way I can think of to avoid programs silently taking screenshots in the background.)
What happens instead is that grim just makes a screenshot, just like on X11.
I searched the bug trackers of some compositors (labwc, sway, hyperland), but couldn’t find any discussions about this.
Aren’t we almost back to square one now … ? The only advantage is that compositors now *could* ask, because there’s a well-defined protocol. But in practice they don’t. Hm.
cc @mckinley since you seem to have some more experience with Wayland.
I’m a bit confused here. One of Wayland’s advantages is to isolate clients better. For example, on X11, any client can read the screen and, thus, possibly sensitive data. That really isn’t too great.
But one valid use case of this X11 “feature” is to make screenshots.
To make screenshots work on Wayland, this protocol exists:
https://wayland.app/protocols/wlr-screencopy-unstable-v1
What I would have expected is that, when I run a screenshot tool (e.g., grim), the compositor asks me: “Hey, that program wants to make a screenshot, is that OK?” (That might be a bit annoying, but it’s the only way I can think of to avoid programs silently taking screenshots in the background.)
What happens instead is that grim just makes a screenshot, just like on X11.
I searched the bug trackers of some compositors (labwc, sway, hyperland), but couldn’t find any discussions about this.
Aren’t we almost back to square one now … ? The only advantage is that compositors now *could* ask, because there’s a well-defined protocol. But in practice they don’t. Hm.
cc @mckinley since you seem to have some more experience with Wayland.
Ah … GNOME does have a dialog for that:
That’s what I would have expected.
(The text in the dialog is a lie, though. I cannot find the corresponding setting to allow/deny making screenshots. 🤷 Whatever.)
Ah … GNOME does have a dialog for that:
That’s what I would have expected.
(The text in the dialog is a lie, though. I cannot find the corresponding setting to allow/deny making screenshots. 🤷 Whatever.)
Ah … GNOME does have a dialog for that:
That’s what I would have expected.
(The text in the dialog is a lie, though. I cannot find the corresponding setting to allow/deny making screenshots. 🤷 Whatever.)
I've been using Grim to take my screenshots on Sway since I started using it in April 2022 and I don't recall giving it explicit permission to do so. This issue suggests Sway doesn't yet support restricting screencopy.
@mckinley Ah, thanks. So that’s the important part, I think:
> To elaborate, I don't want to add new commands or config options or some similar such before we know how security as a whole is going to play out, because we'll have to support them forever and it's unlikely that we'd come up with a solution now that doesn't end up being inconsistent with our later work.
Understandable.
I wasn’t quite aware that things are still “in flux” so much. 🤔
@mckinley Ah, thanks. So that’s the important part, I think:
> To elaborate, I don't want to add new commands or config options or some similar such before we know how security as a whole is going to play out, because we'll have to support them forever and it's unlikely that we'd come up with a solution now that doesn't end up being inconsistent with our later work.
Understandable.
I wasn’t quite aware that things are still “in flux” so much. 🤔
@mckinley Ah, thanks. So that’s the important part, I think:
> To elaborate, I don't want to add new commands or config options or some similar such before we know how security as a whole is going to play out, because we'll have to support them forever and it's unlikely that we'd come up with a solution now that doesn't end up being inconsistent with our later work.
Understandable.
I wasn’t quite aware that things are still “in flux” so much. 🤔