Reported by jteh on 2011-03-22 18:51
The clipboard is not specific to input desktop. I'm not sure what scope it really has, but I'm guessing it is session wide. Unfortunately, this means the user's clipboard can be accessed from the lock screen, which is bad because the user has intentionally locked the computer to prevent access by others. This includes the reportClipboardText script, the review_copy script and editable text fields in our GUI. The first two are fairly easy to disable, but the third poses more of a challenge.
From what I've been able to discover, there is no way to disable clipboard access for an Edit control without overriding the clipboard window messages, which is incredibly ugly. A better solution might be to just disable most of the settings dialogs altogether. My concern is that some of them might be needed; e.g. braille settings (for blind deaf users who are able to open it blind), etc.
Comment 1 by jteh on 2011-03-22 22:27
There are a few other scripts that use api.copyToClip() as well, so we should just disable that function. Also, it's possible to copy text from message boxes by pressing control+c, so standard message boxes are bad too.
I wonder if we could just somehow block clipboard window messages for our entire process?
Comment 2 by mdcurran on 2011-03-25 05:49
Fixed in 2fb1ce7. NVDAHelperRemote hooks OpenClipboard to simply return false and not call the origianl OpenClipboard, if this process is the NVDA process and its in secure mode.
Comment 3 by jteh on 2011-03-25 05:51
Milestone changed from 2011.2 to 2011.1.1