On 14.03.22 18:28, Anssi Saari wrote:
Marco Möller <talby@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 <nickgeovanis@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.