Untrue. KeePassXC has large parts of UI boilerplate code and test cases. The cryptographic routines are the smallest part. They are pretty stable and don't change much. It's also not where we would be using AI.
The statement that correctness plays no role in the training process is objectively false. It's untrue for text LLMs, even more so for code LLMs. Correct would be that the training process and the architecture of LLMs cannot guarantee correctness.
If we're wasting anyone's time, it's our own. Your comment reads like the AI would make up hundreds of invalid complaints, which is simply not true. You can see for yourself in our GitHub repository if you care.
The extra functionality isn't opening security holes. It is central functionality that users have come to expect such as Auto-Type or support for YubiKeys. The Debian maintainer has decided to disable the WITH_XC_ALL flag, which disables ALL optional features (not sure why you consider this a lie).
Your claim that KeePassXC communicates with random webpages is also false. There are two cases in which websites are communicated with (none of them random): a) an optional update check (can be disabled), b) when you click the button to download a website's favicon. Please don't just state things that are not true.
I wouldn't say it's misleading or wrong. It's certainly a bit catchy, but it also aligns with a greater discussion that's going on at the moment. Regardless of the title, most people probably wouldn't or couldn't discuss scientific literature in-depth anyway, but search engine spam is something many can relate to, be it from Google or otherwise. It's certainly a topic we will be hearing about a lot more in the future. Besides, we didn't even anticipate this to be picked up by non-scientific journals that quickly, though the title may have helped. ;-)
Hi, I'm lead author of the study, so I can give some background on this. This is certainly valid criticism and we could have addressed our reasoning for using Startpage in more detail, but it just didn't fit in the paper anymore.
The reason we used Startpage is simply that it's much easier to scrape. We started off checking only Startpage (as proxy for Google) and DuckDuckGo (as proxy for Bing), since they are both simple to scrape and produce stable rankings. Plain Bing, on the other hand, is a lot trickier. You often get different results for the same query and you get blocked much more easily if you send too many. The only stable way to use Bing is via the (certainly not very cheap) API, though even that wouldn't necessarily guarantee the same user experience as the web frontend.
We did notice, however, that DDG (despite being mostly Bing) did deviate quite a bit in their results, so we started scraping Bing as well for a fairer comparison. As for Startpage, we did check it initially and we found the results to be virtually identical, except for a few minor rank differences here and there (which are probably just geo personalisation). The differences may have become larger now that Startpage also taps Bing to a certain amount, though when I do spot checks, the results are still sufficiently similar and they are also sufficiently different from what actual Bing gives you. Most prominently, Startpage/Google give you a lot more YouTube results, which we did another small spin-off study on (to be published at CHIIR this year https://downloads.webis.de/publications/papers/bevendorff_20...). Moreover, we could also measure certain immediate effects of Google's ranker updates in Startpage, which weren't as apparent in Bing. So we are confident that Startpage is a reasonable proxy for Google, though it's certainly something we will keep in mind for follow-up studies.
Why do you want plugins? KeePassXC provides most of what KeePass needs plugins for out of the box in usually much better and more stable and tested quality. KeePassXC will never support plugins the way KeePass does and for good reason. Most plugins are unmaintained and some are outright dangerous to use. Your passwords are too precious to let unverified thirdparty plugins handle them.
If you need external functionality that is not available in KeePassXC, you can try to bolt it on via the KeePassXC-Browser API or open a feature request (or even better: pull request) to get it into the core application.
KeePassX was abandoned years ago, which is why KeePassXC exists.
KeePass is a different product and more like the original inspiration for KeePassX/XC.
The problem isn't so much the language as the fact that it's very tedious if you only have access to the old Win32 API as a result of toolchain constraints. It is much easier with the VCpp toolchain.