As far as I can see, there isn't an option to allow screenshots when editing entries. It would be useful, sometimes, to be able to allow screenshots, e.g. to illustrate issues in Github!
If that's the only reason, I don't think adding an option for that is the most secure. I will look to add this request only if another more important reason is mentioned. I remove the screenshot section from the bug creation pattern.
(since there were several prior screenshot related issues, hope you don't mind if i commandeer and expand this one a bit further into "screenshots and further security considerations")
i just tried KeePassDroid (and KeePass2Android) that this is forked (and borrows) from, and then your app, which seems so much more polished as far as looks and feature set, nicely done.
i'm guessing OP is looking for options like in the KeePass2Android app (which has toggles to block screenshots in the app and recents list, plus request keyboard swap to built in for all data entry unlike Signal app just using disable personalized learning).
while i really appreciate the toggles to allow people to make some more security choices, though, i think that allowing things like screenshots, qr code exports, and built-in cloud storage support... seems like a security liability which i'd rather not have in my password manager tools.
maybe take a look at AndOTP settings for some security ideas. they blank the screen in the recents view without a way to disable that (but screenshots are less an issue for TOTP) but also have options like toggle allow android backup mechanisms, what type of backup to trigger, ripple (panic button app) support and how to respond.
on a similar theme, your toggle to turn off support for things like clipboard, to avoid accidents, is especially appreciated. though considering clipboard is such a well known security issue, and completely unnecessary, thanks to the excellent keyboard and autofill support, you should probably just remove clipboard support entirely.
Thank you for your comment @jmichael2497, it is constructive and illustrates well the philosophy to respect in KeePassDX.
The most complicated is the balance between "allowing the choice to deactivate an important element for security" and "user comfort".
Getting inspiration from other applications is good, but we need to keep a clear guideline that doesn't compromise important elements in software design.
For each point raised:
Versions of Chrome OS appear to prevent the app from working if screen capture is disabled.
Play Store reply -> _"On my chromebox, the app doesn't work because it's on, it only shows a black UI. Same with other security apps. However it worked maybe one or two chrome os releases ago but only for a (OS) release or two, neither before, neither after."_
So I have to check which versions are affected and target them, If anyone has this information it would be nice to give it. :)
See FLAG_SECURE
oh, so from that link it seem whatever is being used, is not considered a secure display device, so they're not able to see the app at all? weird, i wonder if it is using an external monitor instead of the built in display, or if it is running in a vm, otherwise this would break a lot of security apps and get noticed quickly.
@jmichael2497 Maybe an known chromeOS bug?
Here are the versions which apparently do not work.
From Play Store user:
ASUS CHROMEBOX 3, Chrome OS Stable Channel Google Chrome 80.0.3987.158 (Official Build) (64-bit) Revision: af496874d27c92a13415a3a776cc29f9f5ee4e3e-refs/branch-heads/3987@{#1019} Platform: 12739.105.0 (Official Build) stable-channel fizz Firmware Version:Google_Fizz.10139.163.0
quick search of that device specs maybe need to avoid adapters as much as possible? reminds of a multi-monitor issue at an old office.
supports Dual Monitors using HDMI and DisplayPort over Type C for compatibility with legacy display connections like VGA and DVI
Most helpful comment
Thank you for your comment @jmichael2497, it is constructive and illustrates well the philosophy to respect in KeePassDX.
The most complicated is the balance between "allowing the choice to deactivate an important element for security" and "user comfort".
Getting inspiration from other applications is good, but we need to keep a clear guideline that doesn't compromise important elements in software design.
For each point raised: