OpenHashTab icon indicating copy to clipboard operation
OpenHashTab copied to clipboard

Option to disable automatic clipboard reading

Open redactedscribe opened this issue 1 year ago • 7 comments

I think it would be preferable for automatic clipboard reading to be a choice, and therefore able to be disabled. I don't particularly want my clipboard read each time I use OHT unless I give it permission. Currently, no matter what, OHT will attempt to read the clipboard, and sometimes paste in irrelevant text.

I had this in my clipboard and OHT was attempting to check the list of hashes for a match:

---------------------------
Error
---------------------------
utl::SaveMemoryAsFile returned with error: 00000020
---------------------------
OK   
---------------------------

The clipboard reading feature itself could be improved if it is so generous with what it considers a valid hash.

Thanks.

OHT v3.0.2

redactedscribe avatar Jul 05 '22 15:07 redactedscribe

The detection is intentionally very generous, there is an option to make it less generous already (something like strict checking or whatever)

Clipboard reading is an inexpensive operation, why would it be a problem to read it? We need to do that to decide if it contains a hash or not either way.

namazso avatar Jul 05 '22 16:07 namazso

In general, I don't think it's a polite feature of a program to read your clipboard by force, regardless if the source code is open or not. Since this feature is enabled by default, some way to at least disabled it would be appreciated. For example, what if you still had a password of yours on your clipboard that happens to match what OHT thinks is a valid hash and it then decides to paste it into OHT's hash checker field? It would not inspire confidence in the program in my opinion.

redactedscribe avatar Jul 05 '22 16:07 redactedscribe

I'm not a fan of fake permission dialogs / options. It pretends that it's actually a matter of the user's choice whether a program has access to that data, when it's not the case.

namazso avatar Jul 05 '22 16:07 namazso

I guess an option would be possible for the password scenario, as long as it's not worded deceivingly, implying it controls permissions or similar

namazso avatar Jul 05 '22 16:07 namazso

I think it's a good decision. I didn't mean to imply that this would be some Windows permissions setting or similar, but rather only about respecting the user's choice, similarly to how you are given permission to enter a home, nothing stops you from doing it without permission, but it's the polite thing to do.

redactedscribe avatar Jul 05 '22 16:07 redactedscribe

I can see both sides of this. I understand the concern about making a user think that just because they've unchecked an option to not read/use the clipboard, the program can't see the clipboard, when in fact it can, but I don't think that's something you, the developer, should worry about. I'm much more security- and privacy-conscious than most, and I see no problem whatsoever with having an option to "disable" something that the program could do anyways if it wanted. Programs being able to do things outside what the user would expect is a norm and is just a fact of how software works, and they not only do it all the time, but often even when the user tells them not to (Windows is a shining example of this). The fact this is open-source means that if the user says not to use the clipboard, it most likely won't, or there's a decent chance someone will discover that it's doing something it shouldn't.

OTOH, while the open-source aspect alleviates concerns about misusing the clipboard data in the same way, and while a program could certainly do so regardless of any setting, having such a setting would still be nice for a couple reasons. First, it simply provides some peace of mind to the user that they can turn that off and, again, since this is open-source they (or others) can actually verify it. This works toward the issue regarding "politeness" which, while I don't necessarily mind it, since it serves a purpose, I'm aware it's doing it, it's not sending that info anywhere, and it's open-source, is still nice for those that do, and I can certainly understand their concern, as I myself am bothered by similar things various software often does.

Second, it deals with the concern regarding passwords. While a properly set up password manager shouldn't be keeping passwords in the clipboard long enough that this should ever really be an issue, and manually copy/pasting passwords is far from ideal, I don't see this as much of an issue, since it should rarely, if ever, cause a password to be pasted in. However, if it did, and if someone saw it, that could be problematic, though they wouldn't know what it was to and, if it's a good password, they shouldn't be able to remember it just from seeing it for a couple seconds. So I do think that concern is overblown, but not negligible, and it wouldn't hurt to offer the option. One suggestion regarding that to perhaps still allow clipboard use but prevent accidental pasting of a password is to have a button to manually paste the contents instead.

All that said, I personally am not bothered by the current state and would prefer time be spent on other improvements, and again, I'm generally pretty sensitive about privacy stuff. I just don't see this as a real privacy issue, more a perception one.

vertigo220 avatar Jul 08 '22 23:07 vertigo220

I prefer there to be an option to disable it, personally.

JazzMartian avatar Jul 15 '22 15:07 JazzMartian