Dunno how widely used nsILoginManagerStorage is, but its presence is necessary for the Mac-specific Keychain Services Integration extension. That particular case could also be addressed via bug 106400, but it's been open for 16 years now. More generally, it would be great to see password manager vendors to learn to use the login storage interface as well. The built-in login detection and updating logic is way superior to any of the clunky third-party solutions I've tried.

Is that this API or a different one? https://github.com/web-ext-experiments/logins/

(In reply to Andy McKay [:andym] from comment #1) > Is that this API or a different one? > https://github.com/web-ext-experiments/logins/ Different. That one exposes nsILoginManager, not nsILoginManagerStorage.

Hi bintoro, this has been added to the agenda for the April 18 WebExtensions API triage meeting. Would you be able to join us? Agenda: https://docs.google.com/document/d/1zKqhDqXoH9vi88q4DGtOHm1hsCF8ZwLNvCrrCE5htbc/edit# Call-in info: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Details_.26_How_to_Join

At the moment the logins API is awaiting a security review so we can calculate the risks and mitigate the risks for that API. This one would be next on the list behind that in the sense that its the same area and causes similar problems. Personally giving access to this API seems quite risky and I'd be against it, but I'd be interested in security input once the login API is completed. So rather unsatisfying, I think this will have to stay in the holding tank for a moment.

I think this is actually quite compelling. This is all subjective but I think the password manager vendors are often focused on the security and performance of the part of their products that does storage/sharing/etc of passwords. Building a low-overhead browser extension to do password and form autofill is not their main area of expertise but they end up having to do it and doing a job that ranges from passable at best to very very bad in cases (this is not a criticism of them, its not an easy task). Meanwhile, the front end of our password manager and form autofill are built and maintained by folks with expertise in that area but the backend (local disk or Firefox Sync) doesn't have the cross-application support that many users rely on password managers for. By exposing this API to extensions, we would let each of those groups focus on their respective areas of strength. To be sure we're on the same page, I think the security risk is ensuring that a user understands what is happening when an extension uses this api. I think for this to really be useful, ideally it would also let a user migrate password and form data between the built-in backend and an extension provided one when such extensions are enabled/disabled. Perhaps a confirmation notification tailored to explaining what is happening at that moment would be better than just another entry in the regular permissions confirmation dialog?

(In reply to Andy McKay [:andym] from comment #4) > > Personally giving access to this API seems quite risky and I'd be against > it, but I'd be interested in security input once the login API is completed. What are the risks presented by this API beyond those of the logins API? I would imagine they are roughly equivalent in the sense that if an extension wants to steal your passwords, the plain logins API is enough for that. I agree with aswan that the issue is mostly one of informed user consent. We already have third-party password manager extensions around that store credentials outside of Firefox's login storage. Are those going to be banned as well? If not, where's the harm in providing a direct API?

(In reply to bintoro from comment #7) > (In reply to Andy McKay [:andym] from comment #4) > > > > Personally giving access to this API seems quite risky and I'd be against > > it, but I'd be interested in security input once the login API is completed. > > What are the risks presented by this API beyond those of the logins API? I > would imagine they are roughly equivalent in the sense that if an extension > wants to steal your passwords, the plain logins API is enough for that. In bug 1357856, comment 4 and comment 8, people stated that add-on developer use this as a "secure storage". My understanding is that this bug would replace the storage and that the "security" of that storage would now be at the whim of other add-on developers. > I agree with aswan that the issue is mostly one of informed user consent. Informed user consent is easy to say, but much harder to do in practice. That's why we have a user agent like Firefox that we trust to make decisions for us and browse the web confidently with a degree of security. > We already have third-party password manager extensions around that store > credentials outside of Firefox's login storage. Are those going to be banned > as well? If not, where's the harm in providing a direct API? I'm not sure how that comment relates to this API.

> > I agree with aswan that the issue is mostly one of informed user consent. > > Informed user consent is easy to say, but much harder to do in practice. > That's why we have a user agent like Firefox that we trust to make decisions > for us and browse the web confidently with a degree of security. Maybe use phrasing on the download page, or during the install, like, "This extension has access to your passwords, and can choose to store them outside of Firefox." That seems like it should clarify the potential risks to users. > > We already have third-party password manager extensions around that store > > credentials outside of Firefox's login storage. Are those going to be banned > > as well? If not, where's the harm in providing a direct API? > > I'm not sure how that comment relates to this API. One of the (main?) uses of nsILoginManagerStorage / its equivalent, is (as in the Keychain Services Integration extension) to create an alternate storage instance that puts the passwords somewhere other than Firefox's normal password store (such as, the system password manager). This is how this relates to third-party password manager extensions - they could use this API to interface with their third-party password manager's password stores.

Just jumping in as I'm the original developer of the OS X Keychain Services Integration extension. Not much to add beyond what blk, bintoro, and aswan have already said, but happy to answer questions if that's helpful. I particularly like the point about other password manager vendors. It would be really interesting to understand why they don't use the existing interface and whether they would use it if it was different/better. Honestly, I'd kind of given up hope of this interface being supported: I was thrilled when I originally discovered the XPCOM interface and even more thrilled when I was able to reimplement it years later with JS wrappers instead of native code, but changes made to the logins implementation/interfaces over the last few years have led me to believe that support for alternate password managers is just not seen by Mozilla as particularly valuable. For those of us who use the OS X's Keychain extensively to store passwords, support for that is essentially a hygiene factor for a browser and I'll probably stop using Firefox once it's unable to support that. But different people use different approaches to their password storage and I assume I'm in the minority or Firefox would have added native support ages ago (I know a lot of people who use 1Password though, which is why the question about why they don't use the existing interface is interesting) I don't have much time these days, but I've had some challenges with the existing interface over the years so if there is an appetite for a new one, I'll do what I can to feed into it.

Any progress in this issue? Especially in regard of Comment 10 by Julian Fitzell and issue and comments on https://github.com/jfitzell/mozilla-keychain/issues/88.

[Tracking Requested - why for this release]:

The loss of the extension "Keychain Services Integration" is catastrophic for macOS users, who use the mac as they should and want FF on it. The password manager of FF was a bad idea on platform that has an integrated, secure password safe that is really easy to use. The lack of usability for the FF integrated password manager on macOS was fixed by the "Keychain Services Integration" add-on. Have you ever counted how many users set a master password in FF? Without it it's just plain insecure and with one set it's painful to use. That's why we have the keychain on macs and we have macs because we hate painful uis. Using the "Keychain Services Integration" add-on for years collects hundreds of passwords in the Keychain, they are now useless for FF. So now it *really* gets painful to use FF for me at least, since I have to grab every password by hand from keychain and copy it back to FF. That's not an efficient way to work. It's OK if you guys care for a new architecture within FF to make it faster. It's OK to try to enlarge the user base of FF and make the product better. But by disabling such important functionality you loose in the first place users you had for years. So decide now: What is more important keep the guys you had since 0.8 or so or gain some quick switchers that jump off as quick as they came? As an admin I install FF on every Mac, tell my Users to use it. With such a change you render such effort useless, as you do with the browser itself, be it faster, slicker or whatever.

As the KWallet Addon is not working anymore with FF57, this kind of API would really come in handy. Manually creating/looking up logins/passwords is kind of a drag (especially creating new entries), so yeah.. I can still use KWallet for password storage in Chrome. Just saying.

(In reply to Adrian Zaugg from comment #13) > password manager of FF was a bad idea on platform that has an integrated, > secure password safe that is really easy to use. The lack of usability for You seem to ignore that FF wasn't developed for mac only, and "bad idea", however you feel, has nothing to do with your problem. You want to have the means to use the OS password manager, it's not very wise to start debating that some other and different feature (used by lots of people, possibly magnitudes more than that you imply) should not exist since it's a "bad idea" by your personal opinion. Fight _for_ your feature, not _against_ others. Please. > Have you ever counted how many users set a master password in FF? Without it > it's just plain insecure and with one set it's painful to use. "On mac", you possibly wanted to write. When you forget to mention it may be interpreted as you would say "it's painful to use at all", which would open a nice flamewar in a bugreport not really fit for such debate. I only reply to make it clear: the integrated password mgr with master password (and it's proper timeout, which is absent) and proper crypto is essential for a lot of people. Also the required API to manage the login and password db. I do not feel like debating on that one, and it's already been said plenty of places and times. I support API and implementation of external password managers as long as it is possible and feasible not to use it.

Hopeully this gets into Firefox 58. Apple may be a closed-source walled garden, but it is very usable and the experience is seamless. Having integration with keychain is especially valuable on mobile, where it is not so easy to switch apps and autotype passwords.

Ah, Mozilla, I really love you but this is for now keeping me from updating to FF 57. Please consider external password managers and make it possible

A former longtime Linux Firefox user here: making the gnome-keyring integration unavailable (and not reasonably possible to implement, according to https://github.com/swick/mozilla-gnome-keyring/issues/48) in xubuntu made me switch to Chromium. All my credentials are stored in the keyring, and I am not willing to enter a password again when starting Firefox. I hope I be able to return to Firefox eventually, but that Mozilla did not implement a native way of keyring/keychain integration or makes is possible for add-on developers to do so, is a huge usability lapse. If Firefox believes it is the only secure application that a user has installed, then good night Firefox.

This appears to have fallen off the Triage meeting agenda after the 2 May meeting. In fact, all three items from the 2 May meeting were forgotten in the 9 May meeting. https://wiki.mozilla.org/Add-ons/Contribute/Triage#2017 This should probably be revisited during the next meeting (if there's to be one; the last one mentioned was on 28 November).

Hi Greg, it looks like this proposal is still awaiting a security review before it can be approved or denied. Let's follow up by email about any bugs that might have fallen off from the May 2 meeting to the May 9 meeting. We're back to triaging requests on a weekly basis, but the triage wiki has changed. Please update your bookmark to https://wiki.mozilla.org/WebExtensions/Triage. (I'll update the other triage wiki as well). Thanks!

Could Mozilla please look into this with some priority, this is the number one reason I haven't migrated to Firefox 57 yet. Chrome/Chromium already integrates with the system keyring, so they don't need to implement this for their WebExtensions API, so they are unlikely to "take the lead" on this issue. (In fact there this also a long-open bug for Mozilla to do that in #309807.)

A note to those believing that Chrome integrates with the Mac OS Keychain: the feature was dropped a few months ago. See https://bugs.chromium.org/p/chromium/issues/detail?id=466638 Chrome saves the passwords in its own storage and/or in your Google cloud account, depending on your settings. Like Firefox, until this bug is fixed.

As the reporter of this bug, I should disclose that I no longer consider this feature relevant – at least not for the reasons I originally put forward. *** My criticism about external password managers being "clunky" seems to have been outdated. For the past four months, I've been using the latest version of 1Password and am thrilled with it. I have yet to come across a situation that 1Password didn't handle at least as well as the built-in password manager. I now also see why utilising a login storage API is probably not an attractive option for vendors of password management extensions. Since it turns out to be possible to make an external password manager that provides a great experience in the browser as well, it would make little sense to plug into an API that would provide no major benefits but would severely limit what the software can do. *** As for the Keychain... Mac's Keychain Access utility has never been a good password manager. In fact, it sucks horribly at every basic password management task. But the option of storing web passwords in the Keychain was still way better than keeping them solely within Firefox where they couldn't be managed at all. Now the integration no longer works, and I don't think it makes sense to expend significant effort to get it working again. The Keychain lacks basic conveniences such as cross-browser access and cross-device syncing. IMO it would be more productive to improve Firefox's own password manager and enable basic management tasks to benefit those who do not wish to rely on third-party solutions.

(In reply to bintoro from comment #23) > As for the Keychain... Mac's Keychain Access utility has never been a good > password manager. > > Now the integration no longer works, and I don't think it makes sense to > expend significant effort to get it working again. The Keychain lacks basic > conveniences such as cross-browser access and cross-device syncing. IMO it > would be more productive to improve Firefox's own password manager and > enable basic management tasks to benefit those who do not wish to rely on > third-party solutions. While this may be true, using the Mac Keychain offers a few very important benefits: It is a place to store your passwords that is secured by the system, and it is a place where the contents will NOT be sent to the cloud at all if you choose (I am particularly nervous on letting password data hit the wider Internet, even encrypted). The existence of high-quality password managers does not remove the need for integration with the system's password manager.

To summarise there are - In-build password managers (MacOS Keychain, Gnome Keyring, ..) - 3th Party password managers (1Password, Lastpass, Keepass) which have a lot more features and a much wider availabilty then the vanilla firefox Password manager. I think all of them should have the opportunity, to get integrated in firefox. Recently I found a repository which tested out this API proposal https://github.com/mozilla-lockbox/loginstorage-experiment

Missing Keychain Services integration on macOS is currently keeping me stuck on ffox56, which is a security nonsense, particularly now with Spectre around. Please bring this on... don't leave us behind and force us to use Safari or Chrome! Thank You!

(In reply to christoph-wa from comment #25) > To summarise the fewer password managers, the better. A single one, if working well, is the best solution. Everything else leads to chaos and confusion.

(In reply to firefox@firemail.cc from comment #27) > the fewer password managers, the better. A single one, if working well, is > the best solution. Everything else leads to chaos and confusion. Exactly. By implementing the nsiLoginStorage API, this lets the users choose a single password manager they want to use and integrate it with Firefox.

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958