KeePassHTTP Depreciation Warning

[metsatron]

Expected Behavior

I expect continued legacy browser support for Waterfox; Iridium; SeaMonkey & Pale Moon which are currently unsupported by the new browser integration and perhaps never will be.

Current Behavior

My beloved freedom respecting, non-user-subjugating web browsers are being threatened with obsolescence by legacy plugin insensitive deprecation warnings.

Possible Solution

A) Stay on the last supported build of KeePassXC. B) Migrate back to ugly mono KeePass.

Steps to Reproduce (for bugs)

1. Launch KeePassXC
2. Open Database
3. ???
4. Profit... ahhh I mean, observe ominous warning!

Debug info

KeePassXC - 2.3.3 keepassxc-browser - Legacy (PassIFox/chromIPass) Operating system: GNU/Linux Browser: Waterfox/Iridium/SeaMonkey/Pale Moon Proxy used: NO

[phoerious]

My beloved freedom respecting, non-user-subjugating web browsers are being threatened with obsolescence by legacy plugin insensitive deprecation warnings

You mean "your insecure legacy browsers are threatening technology to stop moving forward..."?

Sorry, but this is a hard WONTFIX.

[metsatron]

So your plan is to phase out support for progressive and actively maintained freedom respecting FLOSS projects who still rely on the actively maintained plugin you have labeled "legacy". In favor of regressive, privacy violating, user subjugating proprietary web-browsers because communication between KeePassXC and the browsers is more secure despite the browser itself violating user privacy and freedom? How is leaving freedom behind for the illusion of security moving forward exactly? FYI both Iridium and Waterfox support your plugin. It's only KeePassXC that is unable to communicate with them. why discriminate against projects that support user freedom by labeling them legacy?

[phoerious]

Browsers whose only reason for existence is to keep supporting old plugin APIs are the opposite of progressive and by definition legacy technology.

And I don't see how Chromium or any distribution of Firefox are supposed to be "privacy-violating proprietary browsers". I'm really not sure in what world you live there, but in mine they are as proprietary as KeePassXC itself. If you prefer another browser that does support modern web extensions, feel free to use it, but you may need to adjust the native messaging manifest yourself (we don't discourage their use, but we just can't actively support every niche browser fork out there). But if you prefer a browser that only supports legacy addons, we can't stop you, but don't complain if we keep calling them what they are.

[metsatron]

Firefox and Chromium both contain proprietary binary blob black-boxes and DRM technologies. Mozilla have been involved in numerous scandals revolving around bundled spyware, adware, deploying malware and unwanted 3rd party software/baked-in proprietary plugins. (Let me know if you need references).

Waterfox is kept in line with Firefox ESR builds and is far from being legacy code. Both Waterfox and Iridium support the current KeePassXC plugins (1.2.0). While I don't expect you to support every browser, I don't see how Vivaldi or Chromium are any less niche?

To be clear, I don't expect anything. I didn't pay for this software so I can only say thank you that it exists and is supported in this form at all. I do however like to support developers of software that I highly value and respect, above all in terms of ethics. This includes financially supporting projects that I rely on daily.

Since this is already a FLOSS project it was not a huge stretch for me to imagine you might be interested in both privacy and security. I personally don't want to give up on either for mere conveniences. I have vaguely understood that the new method you are using, which for all intents and purposes is more secure and progressive, requires that the browser be targeted specifically, right?

To my mind the work required to add support for the addition of at least two of these security focused forked browsers that already support the KeePassXC plugin seems trivial at best. I wont insist further, but at least in my case I wont be depreciating my 4 favorite web browsers as long as there are other options regarding KeePass.

Is there a valid reason to eliminate the existing support for the legacy plugin? It seems to only limit user choice?

[droidmonkey]

It would probably be ok to support install of proxy manifest for waterfox. I've never heard of the other browsers though. Collectively they probably amount to 0.05% market share.

[metsatron]

@droidmonkey thank you for considering my request.

From the Iridium website:

Iridium Browser is based on the Chromium code base. All modifications enhance the privacy of the user and make sure that the latest and best secure technologies are used. Automatic transmission of partial queries, keywords and metrics to central services is prevented and only occurs with the approval of the user. In addition, all our builds are reproducible and modifications are auditable, setting the project ahead of other secure browser providers.

The other two web browsers (SeaMonkey and Pale Moon) are as @phoerious pointed out, in all fairness intended to maintain legacy support. However the Waterfox and Iridium browsers support modern code bases and are intended as privacy and security focused alternatives to their user-subjugating counterparts (Firefox and Chromium) and as such should be simple to extend support to.

ungoogled-chromium is another project that selectively borrows many of its features from the following:

• Debian
• Inox patchset
• Iridium Browser

I agree that internationally the market share is low, however here in Germany people are generally much more privacy and security aware. I think it would be wiser to focus on the percentage of KeePassDX's user-base that use these browsers rather than the vast hordes of people who use their OS's default browser and are highly unlikely to even know what a password manager is. If you could make these three privacy & security focused browsers compatible with KeePassXC you would also make the kind of people that are more likely to want to use and contribute to this project very happy! Thank you :+1:

[phoerious]

Waterfox is kept in line with Firefox ESR builds and is far from being legacy code.

We might add some more browsers (if they support web extensions, we won't revive the legacy add-on), but then we should rethink the selection process. Generally, I don't agree with niche browser forks not honouring configurations done for their upstream projects. If you want people to use your application, you should make it a drop-in replacement. That doesn't mean that you have to use the same user profile, but at least respect meta configuration such as native messaging manifests that were installed for Firefox. This might as well be reported as an issue against Waterfox.

That said, if you want to get rid of the legacy warning message, just disable KeePassHTTP in the settings.

[metsatron]

That said, if you want to get rid of the legacy warning message, just disable KeePassHTTP in the settings.

At present this is the only way to support the four web browsers I use which are all active projects. I still rely on the legacy plugins which are all still actively developed.

One more important consideration I forgot to mention earlier is that Thunderbird, the software that perhaps benefits most from KeePass integration (in my case making 10+ credential requests for multiple emails accounts, calendars, WebDAV, address books, etc; at launch and during use) still uses the "legacy" plugin format and shows no sign of changing. Like SeaMonkey they are no longer part of Mozilla Corporation, not organizationally and hence remain free of user-subjugating policies.

To drop KeePassHTTP support will force users of all the applications I have mentioned and several others to revert back on the ugly mono KeePass. It's obviously not the end of the world. But I would love to see this project truly flourish and supersede KeepPass without leaving behind use cases like my own.

I wouldn't have even raised the issue if the support wasn't there to begin with. I simply would not have started using KeePassXC in the first place. I just cannot understand why something that works needs to be removed. I can understand why Apple does it, they make fat profit from removing useful features users rely on. But this is a FLOSS project. Maybe it reduces the attack surface, but in my case renders this killer feature dead in the water. I guess you could always charge money to add it back. I would pay a one time fee for a premium version of KeePassXC with classic plugin support!

[varjolintu]

@metsatron There's one more solution to the problem: a keepassxc-proxy variant that runs KeePassHTTP. User could then use old legacy extensions to connect with KeePassXC using the new protocol and implementation. The downside is that many KeePassHTTP compatible extensions are no longer maintained.

[phoerious]

There are two simple reasons: these legacy addons are insecure by design and we don't have the manpower to support two different addons and we also don't want to. And by any means, "But it works" is not an argument. Java applets or ActiveX components also "work" (or at least they used to until browsers started removing them for exactly the same reasons and I bet people complained about it as well), but we still won't support them for obvious reasons.

[varjolintu]

Related: https://blog.mozilla.org/addons/2018/08/21/timeline-for-disabling-legacy-firefox-add-ons/

All legacy add-on versions will be disabled in early October, 2018. Once this happens, users will no longer be able to find your extension on AMO.

[metsatron]

@varjolintu I'm not particularly concerned about Mozilla dropping support for legacy Firefox add-ons. No one who even remotely cares about privacy and freedom would consider using Mozilla Firefox in this day and age anyway, despite what the propaganda claims on the Mozilla website state about their stance on privacy. The cat is already out of the bag, so to speak. And all of the projects who continue to make use of the evolving Firefox code-base have committed not to remove "legacy" add-on support. The only thing they are interested in removing is telemetry, baked-in 3rd party apps like Pocket and various other unwanted user-subjugating anti-features.

Thunderbird/Add-ons Guide 57 Legacy, pre-version 57 add-ons - Thunderbird 57-60 (and Seamonkey) still support legacy add-ons.

WebExtension aka futures: Thunderbird 60 does not have WebExtensions support. Going forwards, bug 1396172 will add WebExtension support in Thunderbird beta 63, while maintaining "legacy" add-ons and hybrid add-ons.

keebird last updated 9 days ago, is active and maintains support for the KeePassRPC plugin on Thunderbird.

Future of Waterfox

After the add-on store rids the old add-ons, there should be an archive in place where you can access all your favourite classic add-ons. Mozilla still uses legacy extensions internally (albeit they are developed in tandem with browser updates so they don't have to worry about breakages), so lets say we take ESR 60 as base, it's more of a case of exposing them (and seeing what APIs may be missing, re-implementing the add-on SDK and testing, testing, testing) rather than limiting them internally (unless something has changed compared to 57 for the handling of this). Also, I managed to get this working with 57 as a quick experiment - add-ons would just need to be updated as a lot of them failed due to XUL changes.

So these two important projects still rely solely on legacy/XUL plugins. Here we are not simply talking about "niche" web browsers, but rather the most powerful and one of the most widely used email clients. If you end support for legacy plugins you will end support for Thunderbird/SeaMonkey leaving no alternative.

Moving forwards I would like to try your solution, if you could offer some help I will meet you half way. There needs to be some kind of bridge for users of the legacy plugins to continue to do so. Even Apple didn't just drop USB Type-A ports from their devices without at least offering people a "dongle-life" solution. I'm ready for the "keepassxc-proxy-life" if it works then we're all happy right?

[phoerious]

The decision is final. We won't keep supporting legacy addons. Use Auto-Type if you need to use these applications.

[metsatron]

@phoerious with all due respect, please allow @varjolintu to consider the evidence I have put forwards as his stance has been so far much more constructive and I'm interested in the solution his proposing.

@phoerious did you even consider what I just shared above? If you drop legacy addons without providing an alternative you will effectively break support for Thunderbird! Not just all the wonderful "niche" browsers you arrogantly dismissed earlier, but the most powerful and enduring email client in use today!

I rest my case.

[phoerious]

As I said, we just cannot support two addons. And even if we could, we wouldn't want to endorse use of insecure legacy technology. Sometimes you just have to cut old ropes. People will continue using things as long as they are available and we would still all be running Windows XP and Internet Explorer 6 and encrypt our stuff with RC4 (or not at all) had companies not ended support for these things years ago. We cannot and we will not revive KeePassHTTP and insulting us won't change anything about that. The alternative that you want is Auto-Type, which works perfectly for Thunderbird etc.

[varjolintu]

@metsatron I agree with @phoerious here. We cannot support two addons. The previous ones are already missing a lot of bug fixes and there's no one to maintain them. And now when Mozilla is going to remove all legacy addons from AMO, there's no centralized update mechanism but a bunch of archives from different developers. If Google would do the same and remove support for all insecure API's, would you rather transfer to use newer more safer ones or stick to the old stuff because it already works with ancient machines? And like said, Auto-Type works great with many situations.

I am more constructive with ideas that will work together with the new browser integration and protocol. Even the keepassxc-proxy variant thing I suggested keeps KeePassXC clean from any legacy supporting code.

Like you said, Thunderbird is getting WebExtension support eventually, and they already have a small guide for extension developers.

[metsatron]

@phoerious I have not attempted to insult anyone, simply making a clear case. Let's take your example with Windows XP and IE6. Here you're talking about a 17 year old OS which has been superseded by numerous releases from the same developer. Microsoft provided a clear upgrade path. They achieved this without dropping support for applications that were designed to run on Windows XP, you can still run most of them unmodified in legacy mode. So that example does not work in your favor.

In the case I am making, we are referring to current state of the art privacy and security focused products. If the XUL plugins posed such a high security risk as you are claiming, why on Earth would these privacy and security focused projects continue to support classic add-ons? This has nothing to do with supporting ancient machines or any such nonsense. The only point I have been driving this entire time is that by removing a currently working feature in KeePassXC you break support for widely used software which is still actively developed, and without any gain. It's a net loss!

You argue that leaving it is insecure. Yet it's not even enabled by default. That argument makes no sense. At present you are leaving the choice up to the user as to what plugin solution they choose to use. I don't want auto-type, I want proper integration which allows me to save and update passwords from the browsers native interface. I want username and password suggestions. That's part of the functionality currently provided by the still maintained plugin's I am using across all of my browsers and email clients. I don't want to fumble around KeePassXC's UI searching for credentials and pressing auto-type buttons, that's a major regression in efficiency.

@varjolintu KeePassRPC is still actively maintained, the last commit was only 4 months ago. It's a mature and stable plugin, how much work does it need in maintaining it?

KeePassRPC supports multiple clients, although the Kee web browser add-on is the most widely used. Other known uses include Thunderbird integration and integration with old web browsers such as Firefox before version 57 was released in 2017.

The legacy add-ons have already been moved to https://addons.thunderbird.net/en-US/seamonkey/ and https://addons.thunderbird.net/en-US/thunderbird/ respectively Pale Moon has the Classic Add-ons Archive which still receives updates as well as https://addons.palemoon.org/ which also receives updates. So no, not everyone needs to march to Mozilla or Google's corporate drum. You as free open source software developers most of all have the freedom to oppose these imposed corporate policies You also have the freedom to give up your freedom and simply march along with no way back if you want. Just as I have the freedom to stop using your product when it stops working.

Could you please give me a deadline for when you plan to drop support for the legacy plugin so that I can plan my migration path to KeePassX or back to KeePass (proper)?

[varjolintu]

About legacy extension from Mozilla:

Because extensions built with the Add-on SDK can request XPCOM privileges, they could still introduce unintentional security and stability issues into Firefox. Even add-ons written by well-meaning developers can accidentally introduce vulnerabilities that could allow malicious code to execute with the full privileges of the browser. WebExtensions uses its manifest.json to mitigate this by requiring add-on authors to declare up front which permissions their code will need to operate. Unlike the Add-on SDK, WebExtensions does not allow arbitrary XUL/XPCOM access, so even insecure/vulnerable code is limited to its whitelisted subset of functionality. This vastly reduces the vulnerability surface of a WebExtension, leading to faster review times and a more stable browser.

After reading that (and bunch of other stuff), I can only wonder why many privacy and security focused browser forks still want to maintain the support for legacy extensions, and how they are going to improve the security from that start point? Or have they already done so while still maintaining compatibility? Like said, other Mozilla products are going to add WebExtension support as soon as they have the remaining issues resolved. Browser forks are very welcome to add the same features.

The deprecation of XPCOM/XUL based extensions was announced already in 2015.

[Gittyperson]

I successfully use Auto-Type with Pale Moon (left Firefox long ago) and it works just fine - actually, even better not having to install browser extensions. While I agree with some of metsatron's points, I can't possibly push anyone to increase their workload.

However, I'll share my prediction that the so-called legacy/unsafe/old/evil etc. XUL extension technology will outlast the ill-conceived WebExtensions system, and all the hard work some people are doing to adapt will go to waste -again- due to Mozilla's self-destructing course. Sooner, rather than later.

[metsatron]

Hey @Gittyperson thanks for your suggestion and support. I tried Auto-Type. With a hot key it works quite well provided I set up the database entry correctly. The limitation to this method is I cannot save or update passwords through the browser or save all the fields of the current form.

I took another look into KeePassX. It hasn't been updated in 9 months. In which case I'm better off sticking with the last released version of KeePassXC when they finally do decide to drop the hammer on legacy plugin support. It's a shame.

I still don't see how leaving the feature how it is creates any additional work for anyone? It's not enabled by default. Where is the security vulnerability? Only if the user enables it. You can leave a warning saying this mode is less safe. That takes changing a string.

Where is the extra work? I'm probably fighting a loosing battle. But it's just mean leaving people out in the cold like that...

[Gittyperson]

If there aren't any specific vulnerabilities, labelling something as insecure just because it is more powerful is wrong IMO. On one hand, there's Mozilla pushing new things onto users, conveniently denigrating as "legacy" and insecure the older technology (which is more stable and powerful).

On the other, there's the developers who understandably prefer to follow the "main" browser, even though it's becoming less relevant due to the aforementioned changes and decisions. I'll disagree with phoerious' slightly dogmatic "insecure legacy browsers are threatening technology to stop moving forward". For most people, it is clear the "new" Firefox is a serious downgrade over its previous incarnations - and it's not really more secure. Many (not all, obviously) of the "new technologies" are marketing gimmicks designed for company profit, against user benefit and experience.

However, the "legacy" technology is not dead just because Mozilla shifts away. It's there, used and enjoyed by many, being developed and updated. So, axing it as a KP feature just like that seems strange. Offering support and updates for it is another matter -it wouldn't be required much anyway- but I'd also love to have it available.

[metsatron]

Can you please reconsider what @Gittyperson and I are proposing? I cannot comprehend why this is such a tall order? It's not a feature request, it's a "people are still using this feature" request. Why not poll your user base before deciding to cut a portion of them off? You cannot simply go by generic browser statistics. Users of this project are not generic. Why not enquirer as to what browsers actually matter to us before making assumptions?

[droidmonkey]

Certainly we value all our users and their unique circumstances. However, as a volunteer team focused on security and supportable code we cannot afford (time wise) to keep legacy technologies hanging around. Nothing is preventing you from staying with the current version of KeePassXC (after we update to 2.4) and just keep using the old http plugin. You are also welcome to keep your own fork of the project that maintains the HTTP plugin.

[varjolintu]

Btw, I'm already developing an application that works as a KeePassHTTP server (developed based on the parts removed from future KeePassXC's) but can wrap the commands between the new browser integration. It means you can use your older KeePassHTTP-based extensions normally.

It takes time, but I hope I'll have the first release ready by the end of the year. And of course, any contributors interested are welcome to join.

[metsatron]

Btw, I'm already developing an application that works as a KeePassHTTP server (developed based on the parts removed from future KeePassXC's) but can wrap the commands between the new browser integration. It means you can use your older KeePassHTTP-based extensions normally.

It takes time, but I hope I'll have the first release ready by the end of the year. And of course, any contributors interested are welcome to join.

Hey that sounds awesome @varjolintu could you please share a link to your repo so I can follow and contribute?

[varjolintu]

@metsatron I'll create the repo when the application is a bit more ready so it can be actually used a little.

[psvenk]

@varjolintu I am interested in using your application when it's ready. Have you created a repo for it yet?

[phoerious]

This is the repository. KeepassXC-Browser has been in production for over a year. :man_shrugging:

EDIT: or are you talking about the KeePassHTTP wrapper? That one will probably never be officially supported.

[psvenk]

I was talking about the KeePassHTTP wrapper. I'm sorry, I should have been more specific in my previous comment. I acknowledge the lack of official support and the security issues with the KeePassHTTP protocol, but I am still interested in using KeePassHTTP with PassIFox on Pale Moon (because no XUL/XPCOM extension is available for the native messaging protocol used by KeePassXC-Browser).

[varjolintu]

@psvenk I haven't had time to write a single line since November '18. It's very low priority for me.