On 14.03.22 18:28, Anssi Saari wrote:
Marco Möller <ta...@debianlists.mobilxpress.net> writes:
I am not sure if I understood your answer. Is it a suggestion of what
should be of importance, or is it the confirmation that Wayland is
capable to configure clipboard access restrictive like this?
Um, I thought a question mark is a fairly common indication of a
question? I asked a question.
Ah, now I understood. Well, then I try to answer to my best knowledge
assuming that my knowledge is not outdated. I am not a developer and
only repeat what I found stated by others, again not having a reference
but am citing from memory:
On 14.03.22 16:23, Anssi Saari wrote:
> Nicholas Geovanis <nickgeova...@gmail.com> writes:
>
>> Isn't it all about X by design to not be able to safely protect a
>> running X applications to snoop on other running X applications,
>> something like the content of a window cannot safely kept private?
>
> Well, what about something basic like allowing only specific apps to
> read the clipboard? Or maybe just the app that has focus, sort of like
> Android does it.
Wayland does not provide clipboard access restrictions out of the box.
But Wayland, other than X, makes it possible that restrictions like this
could be implemented!
The implementation would have to take place at the level of the
compositor, which is kind of the equivalent of the X Server. As there
could be developed quite different compositors for Wayland, it thus will
depend on the particular compositor in use, if and which security rules
are finally available. In some more or less popular library, making
available to developers of compositors some basic functionality, it is
implemented the restriction, that only an app in the foreground can
write to the clipboard, and only an app in the foreground can read from
it. This should help that a third party hidden in the background can not
interfere with the clipboard while the users copies something from app A
to app B by switching between exactly these two apps.
Better than nothing! But this library has not implemented further
treatment of the clipboard following further rules. For instance it
would depend on an app, if it removes the content from the clipboard
after having received it. Thus, if the user doesn't delete the clipboard
right away, then a formerly hidden app C becoming a foreground app could
read it. And alike, if the user would not switch directly from A to B,
but my mistake brings to the foreground app C before having pasted to
app B and deleted the clipboard content, then app C could have
overwritten the clipboard without the user having noticed it.
Now, which compositor is using this library with at least this
foreground-app-only access rule being implemented, and which compositor
is using a different implementation, and how do the individual apps
finally make use of their right to read/write the clipboard when in the
foreground? This are many unanswered questions.
There is certainly a need of improvement. But at least, if someone would
like to contribute more sophisticated access control functionality,
then, other than X, this, as far as I remember, would be possible in
Wayland.
Regards, Marco.
