I absolutely never trust blindly in such things. I have never seen a plausible explanation why this is a security feature.

When there are dev’s from X11 involved, this is fine and it seems that this leads to decisions which prevent from current X11 issues. But it absolutely is no guarantee that everything is trustable. I’m not that expert, but your mentioned link points in the right direction. But as long this isn’t supported in the wide mass, it’s only a wish…

That window titles can be easily changed is quite true, so all applications I know monitor such changes and abort the autotype on request when a change is made. But as already said, this is not a security feature, at least not a useful one.

Monitoring the application itself makes no sense for a password manager. As you write yourself, it’s easy to customize the title. All applications make use of this. It is already changed when the tab in the browser changes, a new page is loaded or similar. The same is true for non-browser applications. Windows also allows read access to window titles.

What the Wayland developers do is, in my opinion, gross mischief or ignorance regarding window titles. The password manager needs a simple way to assign a window to an entry, which should be the same for all applications. This should be the same for all DE’s, window managers and OS. The simplest is the window title. The status bar makes no sense and an API would have to be the same or at least similar across all DE’s, window managers and OS. Such a thing does not exist. To implement something like that only for KDE is too niche. This would have to be implemented and established, if already for the broad mass. So also for Gnome, Mate, Cinnamon and all the others. Not to forget, this must also work for Windows and MacOS in a similar way.

This is because Wayland doesn’t allow it to read window titles. Keepass and KeepassXC uses the window title to identify which entry to use. If you have no title, you can’t find the entry. That’s why it will not work with Wayland and never will work, until Wayland allows it to read window titles.

XWayland, which is forced with your workaround, is not Wayland.

That’s at least for me, the main reason not to switch to Wayland. I have no idea why Wayland doesn’t allow reading window titles. There is absolutely no security or performance benefit of this behavior. For me it’s either a bug or a design failure. Or simply bad behavior.

Since a lot of API’s are missing on Android and others have unresolved bugs since age’s, it’s no wonder that Extension developers are total unmotivated to bring more effort to migrate their extensions to the Android platform.

Feel free to try it by yourself. Nothing easier than that. Reboot your phone and try to find it via Find My Device or ring it, without to enter your password before. It will not work.

BTW: it doesn’t make sense to exclude security and privacy related things from encryption. Otherwise there would be an unusually high risk to compromise this sort of data.

Find My Device is completely useless until the device is unlocked. As long as it is rebooted and not unlocked, there is no way to detect its location. Since most phones (if not all), use an encrypted filesystem. With such, no service can’t start if the device isn’t initially unlocked after reboot, including Find my device.

This isn’t only a issue with Google’s implementation, it’s the same with other implementations to.

Ohhh nice. I will try that one. Have used only a simple battle mixer and the good old sl-1200 mk2 for several years. Maybe it’s time to try some digital mixer. Nice that there is something for Linux… Thx for the link.

Lock the pc, if you leave and lock the db, if pc is locked, lid is closed and this is absolute a non-issue.

German BSI is sometimes a little bit over motivated ;-)