You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Auto-Type is great. But it's a constant danger to leak passwords by human error. One wrong click by accident and the last focused target can receive your login data.
I want to disable Auto-Type completely for important entries. So I did.
But this disables performing Auto-Type only for the follow cases:
the button in the toolbar
the hotkey shift+cmd+v
open context menu for entry, click on the on the 'Perform Auto-Type' entry
Not for:
open context menu for entry, click on the on the 'Perform Auto-Type Sequence' entry, click on one of the shown sub entries (USERNAME, PASSWORD,...).
Steps to Reproduce
have an entry
disable Auto-Type for this entry (edit entry->autotype->disable auto-type for entry)
open context menu for entry,
click on the on the 'Perform Auto-Type Sequence' entry
click on one of the shown sub entries (USERNAME, PASSWORD,...).
Expected Behavior
Nothing should happen.
Actual Behavior
The 'Auto-Type Sequence' is performed, writing to the last focus target.
(btw. I found out by accident that something happens...I did not expected that after disabling Auto-Type for the entry)
Context
I'm not sure if this is a bug or a hidden feature request by me?
I have Auto-Type per entry always disabled for security reasons (it's just too easy to hit the toolbar button or hit shift+cmd+v hotkey and even clicking the wrong context menu entry can happen!). These direct Auto-Type actions are much more dangerous to trigger unwanted compared to the global Auto-Type in addition.
That all said, I like the possibility to have the 'Auto-Type Sequence' as an reduced alternative, but even that is too dangerous for some entries which are critical when leaked. I wouldn't mind an option per entry or so to control whether I want the 'Perform Auto-Type Sequence' enabled/disabled too.
But as a user handling important data I should have full control about if Auto-Type can be performed or not to exclude the possibility of human error completely when needed.
To use Auto-Type to it's fullest potential without any downsides, I think fine and well understandable control is a key point.
Overview
Auto-Type is great. But it's a constant danger to leak passwords by human error. One wrong click by accident and the last focused target can receive your login data.
I want to disable Auto-Type completely for important entries. So I did.
But this disables performing Auto-Type only for the follow cases:
Not for:
Steps to Reproduce
Expected Behavior
Nothing should happen.
Actual Behavior
The 'Auto-Type Sequence' is performed, writing to the last focus target.
(btw. I found out by accident that something happens...I did not expected that after disabling Auto-Type for the entry)
Context
I'm not sure if this is a bug or a hidden feature request by me?
I have Auto-Type per entry always disabled for security reasons (it's just too easy to hit the toolbar button or hit shift+cmd+v hotkey and even clicking the wrong context menu entry can happen!). These direct Auto-Type actions are much more dangerous to trigger unwanted compared to the global Auto-Type in addition.
That all said, I like the possibility to have the 'Auto-Type Sequence' as an reduced alternative, but even that is too dangerous for some entries which are critical when leaked. I wouldn't mind an option per entry or so to control whether I want the 'Perform Auto-Type Sequence' enabled/disabled too.
But as a user handling important data I should have full control about if Auto-Type can be performed or not to exclude the possibility of human error completely when needed.
To use Auto-Type to it's fullest potential without any downsides, I think fine and well understandable control is a key point.
KeePassXC - Version 2.6.4
Revision: 34a78f0
Operating system: macOS 10.15
CPU architecture: x86_64
Kernel: darwin 19.6.0
The text was updated successfully, but these errors were encountered: