Skip to content

Conversation

@redneck-f25
Copy link

The automatic clipboard sync introduced with fb7e891 (#1993) is a great feature, thanks for the work.

Enable automatic clipboard sync when permissions allow -- otherwise
fall back to the clipboard panel
.

The fallback clipboard panel should be used if the user blocks access to the
clipboard for some reason, or if access is administratively denied (e.g. through
Group Policies in Edge).

One reason for blocking access could be that a supporter does not want updates to the
local clipboard if the remote user copies something to the remote clipboard during
the session.

@samhed
Copy link
Member

samhed commented Nov 14, 2025

The fallback clipboard panel should be used if the user blocks access to the
clipboard for some reason, or if access is administratively denied (e.g. through
Group Policies in Edge).

If it is administratively blocked, I agree. But if the user blocks access, I don't think we should display the fallback clipboard panel.

@redneck-f25
Copy link
Author

If it is administratively blocked, I agree. But if the user blocks access, I don't think we should display the fallback clipboard panel.

The noVNC application inside the browser cannot distinguish if it's blocked by the user or by an organizational policy.

With #1993, a supporter has no access to the remote clipboard anymore if access to the local clipboard is administratively blocked (e.g. for security reasons to not accidentally leak any private information to any web application).

In my opinion, this is a breaking change. The feature of copying and pasting to and from the remote machine might be completely lost under some circumstances.

This PR brings back the previous behavior and well-known functionality if #1993 doesn't work for any reason and make noVNC behave as announced in them PR comment.

Enable automatic clipboard sync when permissions allow -- otherwise fall back to the clipboard panel.

Another option might be to introduce a new setting "Use classic panel" (like "Show dot when no cursor")

@samhed
Copy link
Member

samhed commented Nov 17, 2025

Ok. But if the clipboard is administratively blocked, it seems to make sense to honor that?

@redneck-f25
Copy link
Author

redneck-f25 commented Nov 17, 2025

Of course. And we do not circumvent the policy!

Since the Web was born, the user requested some text from a remote machine and sometimes copies the text into an local file. When there is a form on the page, the user can copy some text from a local file into an input element and send the information to the remote machine. That's the nature of the web and (almost) under the control of the user (C(md|trl)+C, C(md|trl)+V).

Now, with the automatic clipboard sync, it's not under the users control anymore.

Imagine: I have two support-session with noVNC open. In session 1 I need to copy a password from my password fine or from a chat. If this is done and I do not copy something hurtless into my clipboard, it's still there. Now, as soon as session 2 gets focused on pupose or accidentally the content of my system clipboard is sent by RFB.clipboardPasteFrom() to the remote machine without any notification. A remote user or software (e.g. a clipboard history logger) has the password.

To prevent this, a local administrator or user might block access the the Clipboard API. It's not the intension to handicap information exchange.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants