Fall back to manual clipboard manager if the user explicitly denied the clipboard permission

[icedevml]

Hi,

First of all, I've tested the automatic clipboard management feature which is now available on the master branch and I find it really cool, thanks for implementing that!

However, it's worth pointing out that in a plenty of use-cases the user would not trust the VM enough to allow ultimate automatic access to the host clipboard. For instance, noVNC is integrated with certain malware sandboxes like CERT-Polska/drakvuf-sandbox. In such case, the VM is purposely infected with malware, and we arrive into the case where:

1. The noVNC user has a modern browser that indeed supports clipboard management APIs, but
2. They still don't want to take advantage of that and fall back to manual clipboard management tooltip for better control.

Right now, the noVNC will disable the clipboard feature entirely if the clipboard API is available but the user explicitly denied the permission. I think that there is no point of doing so, and falling back to manual clipboard management tooltip is a much better value added.

/cc @psrok1 @msm-code

related #2020

[tobfah]

Hi, the reasoning behind not automatically falling back to the legacy clipboard mechanism was to avoid the confusion that likely arise when a user denies clipboard availability but there's still an active clipboard, albeit manual. This is why we probably don't want to, at least not completely silently, fall back to the manual clipboard.

How would you feel about a toast (produced by UI.showStatus()), shown once when denying async clipboard? We generally want to avoid adding more settings.

[psrok1]

Hello! I'm the maintainer of Drakvuf Sandbox, which uses noVNC to let analysts interact with malware sandboxes. noVNC is a great project, and I really appreciate your work!

Personally I would not find it confusing if the manual clipboard option would be still active when I have denied access to my "host" clipboard for the browser. In that situation, my intention is to prevent arbitrary reads from my host clipboard, not to disable all interaction with the remote clipboard, especially interaction that I explicitly control. In typical use cases, if clipboard control needs to be restricted on the remote side, that decision would usually come from the remote environment rather than the local user.

In case of Drakvuf Sandbox, the main reason users may not want to enable automatic clipboard sharing, and arguably should not enable it, is that the remote machine is a malware sandbox. The VM may be infected with malware that actively monitors the clipboard and sends anything it finds to the attackers operating the malware. It is easy to imagine a situation where someone forgets they have an active sandbox interaction open in another browser tab with clipboard sharing enabled, then copies credentials from a password manager or other sensitive data. In that case it would be great to have an option to disable that feature at all, but it's a bit out of scope of this PR discussion.

The manual clipboard, on the other hand, is much harder to use accidentally. And in case of the sandbox, it is still a very valuable tool to paste additional commands that need to be run for malware to execute.