From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015 BuildID: 2001101516 Mozilla stores passwords (either from the http/ftp password protocol or a secure form) and other sensitive data (auto-fill data for example) in an insecure fashion. http/ftp/pop/imap passwords can be stored in a standard fashion in the keychain so other apps like Interarchy, Fetch, OmniWeb, iCab, etc. can use them. This would also keep them secure from other users or trojans (the user has to explicitly allow each app to access each sensitive datum). It's also very convenient for the user. Reproducible: Always Steps to Reproduce: 1. Save a http or ftp password in mozilla Actual Results: Data is stored insecurely and isn't available to the user's other apps. Expected Results: Something better

Confirming as an RFE; editing Summary and changing Component to Security: General.

Clearing URL and also setting OS=All.

reporter: your bug reports consistently include bad generalizations and blatantly wrong assertions, which makes using them hard. 1. Mozilla can encrypt the data it stores for users. I'm going to correct your expected results: s/better/different/ brought to you by apple. Think Different. This messy request affects Cookies/Form Manager [morse] + PSM [lord]

I suggest the first step of MacOS keychain integration is to allow the (optional) password Mozilla uses to encrypt personal information (passwords, certs, etc) to be stored/fetched from the MacOS keychain. That gets 95% of the benefit of MacOS keychain (OS-wide single-sign-on) without the pain of trying to re-architect Mozilla's storage for personal information around an OS-specific service. I'm honestly not sure it's worth the effort to get that other 5% of functionality (share certs and web passwords between web browsers). I certainly would put other MacOS/Mozilla integration problems (Internet Config, Page Setup, Java menus, UI consistancy) at a much higher priority.

This integration was already done by Apple and it was working in gromit. Then when we changed the codebase, Apple dropped out of the picture and hence the integration work that they did suffered bit rot. If anybody wants to see what they have, and to pick it up off the floor and get it working, take a look at extensions/wallet/src/singsign.cpp and search for the compile-time variable APPLE_KEYCHAIN. Currently that variable is turned off.

It would be nice to see this on Mac OS X too. I agree the most sensible first step is to implement some sort of "Retrieve master password from Mac OS keychain" option.

Future...unless someone else wants to take it. I won't be working on this anytime soon.

This would be a great addition. Leave Platform as Mac but change OS to ALL since both Mac OS 9.x and Mac OS X 10.x use Keychain. Keychain is not included on Mac OS versions before 9.0. I don't have the programming tools/time/knowledge to fix this myself but I would encourage those of you who do have the time and the resources to work on this. Voting for this RFE...

Chimera does this - maybe we could use code from there. Steve, any interest in hooking up Password Manager to the Mac (OS X) password storage system?

As you noted Chimera does use the Keychain (the patch came mostly from an external developer I believe) and it's gotten lots of positive feedback so yes, we should do it for Mozilla. Putting on my list but keeping the future milestone for now. I wonder if I can con, er, persuade Apple into resurrecting the code they wrote once before :-)

As Dagley mentioned, it was done once before, but it all got killed along with the death of gromit and never resurrected. It was done by an apple employee assigned to the netscape campus. Her code is still in the password manager module but is commented out and has suffered severe bit-rot during the intervening years.

Changing OS to OSX since this seems to still be wanted and support for mac classic is dead.

I strongly disagree that 95% of the benefit of keychain is what you've described. Keychain allows groups of or all passwords to be locked or unlocked on a timed interval. That is useful, but the major benefit for me is using the same stored passwords between different internet applications, with the user's permission. Whenever I need to reset Mozilla or Firefox, all the passwords are lost. When resetting Camino, the passwords are still there. Also, it is silly to make up data like "95% percent of the benefit". Statements like those have no credibility. In reply to comment #4) > I suggest the first step of MacOS keychain integration is to allow the (optional) > password Mozilla uses to encrypt personal information (passwords, certs, etc) to > be stored/fetched from the MacOS keychain. That gets 95% of the benefit of MacOS > keychain (OS-wide single-sign-on) without the pain of trying to re-architect > Mozilla's storage for personal information around an OS-specific service. > > I'm honestly not sure it's worth the effort to get that other 5% of functionality > (share certs and web passwords between web browsers). I certainly would put > other MacOS/Mozilla integration problems (Internet Config, Page Setup, Java > menus, UI consistancy) at a much higher priority.

*** Bug 240927 has been marked as a duplicate of this bug. ***

adding a URL for some sample code from Apple for manipulating the keychain. Something to keep in mind would be multiple user profiles for the same user, so if one were to store the master password you might want to use something like: "org.mozilla.browser.SoftwareSecurityDevice.$ProfileName.MasterPassword" for a service name where $ProfileName is the name of the active profile, otherwise multiple profiles would step on each other. I don't see a mechanism for dealing with this directly, so it would be necessary to pick a convention and stick to it. I'd take a stab but I'm stuck on pots dialup for the time being...

Mozilla (and Firefox for that matter) should make use of existing keychain entries, not merely add their passwords to keychain. There are some browsers which will automatically recognize existing keychain passwords, even immediately after being installed. There are some others which use the keychain to store their own passwords, but do not recognize the existing passwords. These require that the user manually enter the passwords for each web site even though the password for the site is sitting there which is an inferior implementation in my view. Though not a part of this bug, Mozilla should use other OS X unique features such as "services"

<AOL>Me too</AOL> This would also increase the default security, because the Apple keychain has a password by default, and there are tools that will do things like locking the keychain after a time or after a screensaver is run.

I'm not sure if this should be entered as a separate bug, but, ideally, once Mozilla has been integrated with the keychain, there should be some migration tool that will basically export stored passwords from Mozilla to the Mac OS X Keychain, either as a separate utility or automatically (upon first run?). This has several benefits, but mainly that users can use Mozilla apps now without having to worry about manually migrating passwords to keychains later. Any such tool should take probably into account some of the points raised in comment 16.

(In reply to comment #15) > Something to keep in mind would be multiple user profiles for the same user [...] I'm a bit unclear as to why one would care about the master password for multiple user profiles when relying on the Mac OS X keychain for password management? Instead, I would suggest that the security prefs for a keychain-enabled Mozilla app should allow the user to select the keychain(s) to use with that profile. The default for all profiles would be to use the "login" keychain. Users could then specify whether to create/use a new, different keychain (with its own password) for individual profiles on an as-needed basis.

how about this? 1) upon profile creation, a master password is created (user-defined or random) and stored in the login keychain. this is retrieved by FF when loaded each time, and used to decrypt the passwords etc stored by FF during normal use. this could be the default setting, and mean that all info is secure "out of the box". 2) option to change that password / use a different keychain 3) in Camino, all passwords are stored as individual entries in the keychain. this allows other apps to acces & use them (with the users approval) but does lead to a very full keychain. (and the other apps need to know how to read them) i think that as long as the encryption used by FF in its password file is solid, then just having the master password in the keychain is sufficient.

(In reply to comment #20) > how about this? > > 3) in Camino, all passwords are stored as individual entries in the keychain. > this allows other apps to acces & use them (with the users approval) but does > lead to a very full keychain. (and the other apps need to know how to read > them) i think that as long as the encryption used by FF in its password file > is solid, then just having the master password in the keychain is sufficient. Storing the FF master password in a keychain is not an appealing solution. A fully-integrated solution akin to Camino's would be preferable to most Mac users. Benefits to proper keychain integration on Mac OS X include: * It's possible to store some items in non-login keychains that have their own passwords. This allows some passwords to be secured at a * Users can more easily take advantage of tools such as the Password Assistant for generating unique and strong passwords. * Keychain Access is a much better UI for browsing stored account info than Firefox's similar UI. * Using keychains at a fine-grained level enables overall better integration with the Mac OS X platform and other keychain aware applications and tools in a way that just storing the master password cannot. Also, the idea of a "very full" keychain isn't really relevant. I know, I've got one. ;-) Keychains are either used as a database by apps that interface to them (e.g. browsers), in which case size is irrelevant because the app automatically handles lookup. Users browsing keychains directly will use Keychain Access, which has great and fast search functionality that makes it trivial to find the desired keychain item(s).

(In reply to comment #21) > Also, the idea of a "very full" keychain isn't really relevant. I know, I've > got one. ;-) I'll second that - the only way your keychain becomes large is because you're logging on in many places. If you have that many different accounts to keep track of you really want to have a database handling it and the value of sharing that database among every application (particularly other browsers and applications like newsreaders which include browsing functions) only becomes greater.

> * Keychain Access is a much better UI for browsing > stored account info than Firefox's similar UI. I don't accept this as a reason to use Mac OS X's Keychain system. It just means Firefox's UI needs to be fixed. ;-) (I agree with everything else though, and would love to see Firefox fully support Keychain!)

(In reply to comment #21) > * It's possible to store some items in non-login keychains that have their > own passwords. This allows some passwords to be secured at a Oops, that thought finishes: "... secured at a higher level than the typical default to allow FF automatic access to items in the login keychain for the logged-in user." (In reply to comment #23) > It just means Firefox's UI needs to be fixed. ;-) That too, but that's another bug. :)

*** Bug 339615 has been marked as a duplicate of this bug. ***

I would also argue that integrating Mozilla's/Thunderbird's/Firefox's security system with the Mac Keychain provides an additional bit of security just through improving its consistency with the rest of the OS. For example: a Mac can be set to lock the Keychain upon entering sleep (or even, with a third-party add-on, locked when the screensaver is activated). In this case when waking the Mac, everything is locked up - except for running Mozilla processes, which will be in the same state they were in before the machine was put to sleep. It does not seem particularly reasonable to expect the user to use the "clear private data" option, or to shut down all Mozilla processes, prior to sleep - that largely defeats the purpose of using sleep mode.

Considering: - the age of this bug - the high number of votes - Camino aleady has this feature -- which proves that an integration w/ shared Mozilla codebase is possible - Camino (open) source code has the same licence as Firefox source code -- which would make lifting code from Camino code base to Firefox code base possible An info: will be in Firefox 1.x, 2.x, or 3.x would be a great start

I realize this is not a particularly original thought, but it would be good - if it's practical - to do this in an extensible way so Firefox/Thunderbird/etc. on other platforms could take advantage of this enhancement without having to completely start from scratch. For example, it might be possible/desirable to tie this in with the Gnome keyring manager on Linux, down the road.

In response to Comment 28: Yes it would be great. But *please* implement the OS/X feature now and figure out how to genericise it later. Don't make us wait another 5 years to come up with a generic solution.

I don't think Firefox's password stuff should be switched to Keychain. It would cause a dialog to appear on every app update, and it would hurt users trying to use Firefox on multiple OSes or switch between OSes. I'm not convinced that Keychain provides any real security, given that apps can fiddle with each others' address spaces, config/profile files, and executables.

Unless you have found a security exploit that is unpublished, Keychain is as secure as the password you use. I can not imagine how you think that implementing this would impair use of Firefox on other platforms (please explain if you wish). Keychain also has the ability to manually add a web site which Firefox does not yet. There are also any number of web sites that, for one reason or another, do not show up in Firefox with their password. Part of the benefit of using Keychain is that the browser should access existing Keychain User ID/password information, as a number of other browsers presently do. (In reply to comment #30) > I don't think Firefox's password stuff should be switched to Keychain. It > would cause a dialog to appear on every app update, and it would hurt users > trying to use Firefox on multiple OSes or switch between OSes. > > I'm not convinced that Keychain provides any real security, given that apps can > fiddle with each others' address spaces, config/profile files, and executables. >

> Unless you have found a security exploit that is unpublished, Keychain is as > secure as the password you use. I'm just guessing based on seeing that gdb can attach to processes, vim can edit files in my Firefox profile, etc. I haven't tried to put together a complete exploit; it just seems obvious to me that an operating system that doesn't carefully protect applications from each other can't have secure per-application storage. (And that's ignoring the fact that on the occasions when Keychain does show a warning dialog, such as application update, the dialog doesn't give you enough information to decide if it's a legitimate update.) > I can not imagine how you think that > implementing this would impair use of Firefox on other platforms (please > explain if you wish). Currently, users can move Firefox profiles from Mac to Windows without losing their passwords. They might even be able to use a single profile from multiple OSes for an extended period of time. Storing passwords on Mac outside of the profile would partially defeat those use cases.

> Currently, users can move Firefox profiles from Mac to Windows without losing > their passwords. They might even be able to use a single profile from > multiple OSes for an extended period of time. Storing passwords on Mac > outside of the profile would partially defeat those use cases. That's a good point, but hardly a deal-breaker. The reason why I don't use Firefox on the Mac is that it doesn't feel or behave like a Mac application. This is something everyone notices as soon as they try Firefox on the Mac. I would have to guess that this is much more relevant to most users than being able to copy Firefox configuration files from platform to platform. Obviously, Keychain integration won't solve the entire problem, but it's a step in the right direction. But let's suppose you're right, i.e. that there are a significant number of people who will not use Firefox because it's more important for them to share their data with Firefox on another OS than with other apps on the Mac. Isn't this functionality part of the cross-platform library? Can't we just make a preference "use firefox/use keychain"? Not wanting to take it out doesn't doesn't seem like a valid reason not to implement Keychain support.

(In reply to comment #32) > complete exploit; it just seems obvious to me that an operating system that > doesn't carefully protect applications from each other can't have secure > per-application storage. (And that's ignoring the fact that on the occasions The Keychain is not perfect but any application will share those flaws; it does have key advantages over Firefox's current implementation thanks to the lock on sleep/screensaver option and offers some protection in the event of a less than total compromise (e.g. my online banking password can be set to prompt before each use so an attacker who can run JS can't try to silently load things in the background). The big reason for this, however, isn't security since all desktop operating systems share this problem. The win comes from interoperability and the better keychain UI: I'm a geek who actually cares about things like better features, interesting extensions, etc. and I still find myself using Firefox mostly for web development because it's inconvenient to have to re-enter all of my passwords or deal with a non-searchable UI. Safari, OmniWeb, and Opera have closed the standards gap significantly and are quite competitive on performance so this is actually a fairly significant competitive disadvantage for the Mozilla products.

> The reason why I don't use Firefox on the Mac is that > it doesn't feel or behave like a Mac application. Let's not make Firefox worse just to make it "feel more like a Mac application". > I still find myself using Firefox mostly for web development because > it's inconvenient to have to re-enter all of my passwords You have to do that when switching from Firefox to Safari too. I don't see how that puts Firefox at a competitive disadvantage.

(In reply to comment #32) > > Unless you have found a security exploit that is unpublished, Keychain is as > > secure as the password you use. > > I'm just guessing based on seeing that gdb can attach to processes, vim can > edit files in my Firefox profile, etc. I haven't tried to put together a > complete exploit; it just seems obvious to me that an operating system that > doesn't carefully protect applications from each other can't have secure > per-application storage. (And that's ignoring the fact that on the occasions > when Keychain does show a warning dialog, such as application update, the > dialog doesn't give you enough information to decide if it's a legitimate > update.) There is always Apple Feedback <http://www.apple.com/macosx/feedback/> if you think that Keychain is not secure. You won't get an answer as such as Apple does not comment on security maters, but it should be reviewed by the right people. > > I can not imagine how you think that > > implementing this would impair use of Firefox on other platforms (please > > explain if you wish). > > Currently, users can move Firefox profiles from Mac to Windows without losing > their passwords. They might even be able to use a single profile from multiple > OSes for an extended period of time. Storing passwords on Mac outside of the > profile would partially defeat those use cases. OK, fair enough. I thought you were getting at something else. As I understand it, the proposal is to allow the option to use Keychain instead of the Firefox password saver which would let the user choose. Still, it would be useful to be able to export passwords and such in a Firefox format in much the same way that bookmarks can be exported. I do not know if this capability has been discussed as a part of the proposal. Cheers

> Let's not make Firefox worse just to make it "feel more like a Mac > application". Is that a serious comment? Clearly most of the people here are arguing that Keychain is far superior to what Firefox currently provides. But the argument about what is "better" or "worse" is misguided. If Mac users are not using Firefox because it doesn't behave naturally or intuitively to them, isn't that something the development team should be concerned about? Regardless of whether they feel those users are stupid or not?

(In reply to comment #35) > > I still find myself using Firefox mostly for web development because > > it's inconvenient to have to re-enter all of my passwords > > You have to do that when switching from Firefox to Safari too. I don't see how > that puts Firefox at a competitive disadvantage. Firefox is not the default browser - that means it's best to provide fewer annoyances for people considering a switch. It's also the only major Mac browser which doesn't use the Keychain so it's really a divide between Firefox and most other Internet-facing Mac apps (OmniWeb, Opera, most newsreaders, FTP clients, etc.), not just Safari.

(In reply to comment #38) > (In reply to comment #35) > > > I still find myself using Firefox mostly for web development because > > > it's inconvenient to have to re-enter all of my passwords > > > > You have to do that when switching from Firefox to Safari too. I don't see how > > that puts Firefox at a competitive disadvantage. > > Firefox is not the default browser - that means it's best to provide fewer > annoyances for people considering a switch. It's also the only major Mac > browser which doesn't use the Keychain so it's really a divide between Firefox > and most other Internet-facing Mac apps (OmniWeb, Opera, most newsreaders, FTP > clients, etc.), not just Safari. > Any update? Is there any plan to add keychain support? I try to use Firefox because of the Adblock plugin. But I have to use Camino or Safari when logging into sites. Another alternative is for Camino to support adblock plugin.

What I like most about Keychain is that it keeps all your password and related data in one place. You do not have to enter the same password into 5 different browsers and other applications for a particular website -- just add it once and you're done. It's just plain annoying when you have to enter it over and over and over again. Other strengths of Keychain have already been mentioned. > Currently, users can move Firefox profiles from Mac to Windows without losing > their passwords. They might even be able to use a single profile from > multiple OSes for an extended period of time. Storing passwords on Mac > outside of the profile would partially defeat those use cases. Nothing prevents an implementation to store passwords in two different places and/or provide an exporter.

(In reply to comment #40) > What I like most about Keychain is that it keeps all your password and related > data in one place. ... and that place can be a removable device so your passwords can be removed if the machine is sent in for repair, or shipped, or has to leave your hands at any time.

It looks to me like there's two reasonable use cases when firefox is running on a mac. For a typical Mac user, it would be convienent for firefox to use the system keychain. However for someone who's bouncing around between a bunch of different operating systems, using the current firefox keychain looks to be more useful. Should this be handled by a preference on the privacy->password tab or should it be a hidden option or some other solution?

I suggest using Keychain by default (for the typical Mac user), with a hidden preference to use the cross-platform Password Manager. Users who are advanced enough to be sharing their saved passwords across multiple platforms ought to be able to handle setting a hidden preference, as long as it's clearly documented somewhere.

I have invested dozens of web site, POP/IMAP, and ftp/sftp passwords into my keychain through Safari, Mail.app, Transmit and other apps. I have my keychain automatically backed up to a remote server regularly. If Firefox and Thunderbird supported the keychain, then I could freely pop back and forth between apps. As it stands, I will not choose to switch to Firefox. What's the big quandry? Give the user an option to synchronize any accessed password between the Mac OS Keychain and Mozilla's password database -- store them all in both places (and later any cookie, form data, bookmark, etc.). Those who want to can then switch freely between Safari, Firefox/Mac and Firefox/*nix. This can be extended to other OS keychains: Mozilla software can be the bridge that lets me move freely between platforms.

PS: I just posted that last comment with Camino for the heck of it, and it's lovely the way it grabbed the login and password I had established using Safari. Cheers.

(In reply to comment #44) > store > them all in both places (and later any cookie, form data, bookmark, etc.). That's fine if it's optional. My keychain is on a CF card. I don't want copies of those passwords anywhere else.

(In reply to comment #36) > There is always Apple Feedback <http://www.apple.com/macosx/feedback/> if you > think that Keychain is not secure. You won't get an answer as such as Apple > does not comment on security maters, but it should be reviewed by the right > people. > A better location to report issues is http://bugreporter.apple.com. It requires a adc account (free), but you get a report id and an audit trail. It's not as responsive as bugzilla, but it's definitely a step up from the feedback form

Just a note for those who require this functionality now. I just tried 1passwd and it works beautifully: http://1passwd.com/ Hope that helps some folks. Chris

So I just found this slip after looking to see if anything existed yet to allow me to use the mac os x keychain with firefox. I have put off using firefox for several years because of this issue. Once keychain was born I have refused to let my passwords get all spread out again. I can sync them between machines with .mac, find them with any app, look them up with keychain access, etc. It is great. As a mac user, this whole debate seems ridiculous and the issue seems cut and dry. Firefox NEEDS keychain integration. I can see, though, how as a firefox user someone could have concerns over firefox portability. That is legitimate. However, on OSX there needs to be a way to choose this option for those who wish it, and I dare say it should be default behavior, as most of the computer n00bs out there only see it as annoying to have to enter passwords twice. The issue of portability affects only a few geeks who understand how to do that sort of thing, know that it's possible, etc. Hidden preference, drop down/radio button choice of "Mac OS Keychain" or "Firefox Password Manager", whatever.

(In reply to comment #49) > As a mac user, this whole debate seems ridiculous and the issue seems cut and > dry. Firefox NEEDS keychain integration. Hear, hear! The few people I've tried to convert from Safari to Firefox have balked at this. They have a lot invested in their existing keychains. Happy Birthday, BUG106400, you're 5 now! I understand that there must be other priorites, but this one seems pretty important if getting Mac users to switch is considered to be important. (Is it? Maybe not...)

(In reply to comment #27) > - Camino aleady has this feature The way Camino does it I end up with separate keychain entries for Camino and Safari. Ideally there'd be only one entry per site, and all browsers would use it.

> I understand that there must be other > priorites, but this one seems pretty important if getting Mac users to switch > is considered to be important. (Is it? Maybe not...) Myself and another developer are currently working on an implementation to this bug. :)

(In reply to comment #51) > (In reply to comment #27) > > - Camino aleady has this feature > > The way Camino does it I end up with separate keychain entries for Camino and > Safari. Ideally there'd be only one entry per site, and all browsers would use > it. That's now (partially) fixed in Camino. Unless you are working on fixing this bug, please do not comment here. It wastes the developers' time and is generally unhelpful. Please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Thank you.

it looks like there is some work being done on this already http://zenit.senecac.on.ca/wiki/index.php/OS_X_Keychain_integration

These two files should be a good start for anyone interested in tackling this bug. I don't foresee myself having any time to work on this.

(In reply to comment #56) > These two files should be a good start for anyone interested in tackling this > bug. I don't foresee myself having any time to work on this. I would add that the patch in bug 309807 can be a useful resource too (equivalent bug for Gnome Keyring).

I think the optimal solution would be to find a way for Weave to have access to the OS X keychain. This would kill two birds with one stone. In OS X the keychain would be the main repository for secure password storage, but it would also be accessible to Firefox on other platforms. This could either be transparent for Mac users or be a hidden preference so that Firefox users that prefer the built in password manager could continue to do so. I'm surprised that Weave hasn't ben brought up in this discussion, but it looks like it's been awhile since anyones commented on this issue. Pipe dream?

Comment on attachment 271239 [details] starting code (.cpp file) fwiw.... if (scheme.EqualsLiteral("http")) return kSecProtocolTypeHTTP; else if (scheme.EqualsLiteral("ftp")) you should lose the |else| for each of these. nsCString serverName = NS_ConvertUTF16toUTF8(aHostname); is definitely not good style. if it isn't mutable, you could do: NS_ConvertUTF16toUTF8 serverName(aHostname);

Anybody are to work on this? Would a bounty help advance this? I'm not sure I can get bounty money for it, but I'm willing to try if someone tells me they can work on it if funded.

I decided to try implementing this as an Extension. It's not totally complete yet but it's basically useable so I put up a pre-release version: https://addons.mozilla.org/en-US/firefox/addon/13509 The major missing feature at the moment is the ability to import your existing FF passwords. You won't have access to your existing FF passwords as long as the extension is enabled (you will have access to Safari's saved passwords though). It also tends to over-prompt for permission to access a stored login even in cases where it doesn't really need the password; this is a challenge of the existing login manager API that I haven't quite found a workaround for yet. You won't really see any evidence that the extension is loaded except that passwords will now be saved in the default Keychain. Should work on OS X 10.3 (I think) and up, Intel or PPC, and FF 3.x. I'd appreciate feedback if you get it working or have problems (don't post it here - either on the Mozilla Addons page or by email, please).

Thanks for the work. Does it support certificates and -authorities too?

No. It implements the nsILoginManagerStorage interface, which does not, as far as I can see, deal with either certificates or authorities. I suppose if there is an appropriate API for providing those, that would be a natural thing to add to the extension at some point but it's not a priority for me right now.

Thanks so much for working on this issue, it is the one reason I don't use FF on the Mac. I just tried the extension, Mac OS 10.5.7, FF 3.0.11. In the two minutes I've tried it, it worked great on Facebook and Google, but oddly enough didn't populate the bugzilla.mozilla.org signin page. It did prompt me for access to the keychain for it, but it didn't work, even though Safari did remember the information. I'll keep testing it, but so far, great work. If it could push into the Keychain in a way compatible with Safari, I'd be all set!

Indeed... ah, I see. A typo was causing all new keychain items to be created as the "default" type, which is not correct for form logins. My guess is that your facebook and google logins were already in the keychain from Safari but you added the bugzilla one with the extension? I'm pushing 1.0a7 out, which works for me, but you'll have to delete the existing keychain entry (which would have been created with the wrong type). Keychain items should be more or less compatible with Safari - I'd certainly like to know of cases where they aren't working interchangeably in the two browsers. We should be able to get most of them ironed out though are are a few tricky compatibility issues.

>My guess is that your facebook and google logins were already in the keychain from Safari but you added the bugzilla one with the extension? No, unfortunately not. I haven't added any entries through the extension, all of the entries are from Safari. (And they all work in Safari). If there is any information I can provide from the keychain (that doesn't give anything away, obviously), let me know. Feel free to email me directly if that would be easier.

Hey guys, Talking about bugs in an add-on is going to make this bug harder to fix when a developer comes around to actually implement it because he/she will have to read all the comments that are not actually relevant to the bug. Please take the discussion to a different place.

Agreed. As I said, please don't comment here; either leave a comment on the add-on page or send me an email. I was planning on setting up a Google Code page at some point eventually anyway so I just went and did that: http://code.google.com/p/mozilla-keychain Feel free to post bugs there.

> Platform: PowerPC Mac OS X Can we change the platform of this bug to include Intel? Thanks. Also: the URL is outdated. Apple's more recent summary guide to Keychain Services in Mac OS X is at the redirect from <http://tinyurl.com/keychain-services>.

Although marking this as blocking-, I think this would be a super great enhancement for Firefox. Anyone interested in working on it (or continuing the existing work) should co-ordinate with Mossop and josh in #developers or #fx-team

I wanted to note that I looked into using the Keychain as a replacement. At the time it didn't seem like a good option because of the limited fields that could be stored in the Keychain. We could store additional information in Secure Notes (I think), but it seems like a less than optimal solution. That means at least one additional sqlite call per entry vs the current 1 (since the keychain is just a sqlite db). I think there's also an inherent problem with chrome:// passwords (usually stored by extensions, Weave for example). I didn't get too look into too much detail, but you have to associate a protocol with each entry and chrome isn't one of them. I'd be more than willing to look at this again though & lead an integration project (if deemed a good idea). jfitzell, would you be willing to put the source & relevant build instructions up on the Google Code project? As a side note, I filed bug 496660 as a possible alternative to using Keychain for storing logins. We don't get the shared data with Safari, but it might serve as a OK alternative.

Sorry to get all naive uppity non-implementing demanding user on you, but "it didn't seem like a good option because of the limited fields that could be stored in the Keychain" seems irrelevant to end users' interests. What I (and I suspect others) want is to have Firefox (and Thunderbird) store and retrieve username/password pairs in the same way that other Mac programs do, in particular Safari. I think that a technically superior solution that doesn't do that is missing the point from a value to the application user perspective, and that a partial solution that just uses the Keychain to store one master password and keeping all the FF data independent is probably a waste of the implementer's time. I'm of course not actually volunteering to do any work. Talk is cheap. But I encourage those who actually do productive coding to not let the perfect be the enemy of the adequately good. Laptop-wide, *application-independent* (host,username,password) or (url,username,password) strored data are what I want, and on the Mac platform that of necessity means that doing whatever it takes to play nicely with the MacOS Keychain and with whatever Safari does with the Keychain, even if it isn't a perfect match with The Mozilla Way or something. And yes, I am trying to be constructive.

Agreed with Richard Mlynarik. Safari/Camino/etc. interoperability is the whole point of this bug. We don't want to use the keychain because we enjoy using the keychain, we want to use the keychain because it keeps our passwords across applications. Keychain is the system-wide password store, and using it provides real benefits to end-users.

I will definitely post code for my extension, just haven't got around to it yet. I agree with several other comments that the whole point is to play nicely with the way other apps work on Mac OS (or Gnome or whatever). Having a "better" system that doesn't integrate nicely really is of limited value to users of these platforms. Obviously this is tricky but surely not trickier than any other platform compatibility issue. There may be value to having an option to store the master password in the Keychain (something I'll add to the extension if I can figure out how) but that is really a different feature. The nsILoginStorage interface, although pluggable, is still pretty specific to the existing implementations (not surprising since there aren't real alternates yet). There are ways it could be improved to make things more flexible. For one, it would be very useful to have a separate operation to request the password (Keychain Services only requires authentication to get the password and since I currently need to fill the password into every nsILoginInfo, you end up getting an authentication prompt when searching instead of when you actually start filling in the username and password). I ran into a problem similar to the chrome:// URLs with the ScribeFire plugin which stores passwords for URIs (not valid URLs) like performancing:http://foo.com/bar. At the moment, I'm just passing those through to the mozStorage implementation but they could also possibly be stored as Generic Password items in the Keychain. Chrome URLs could probably be treated similarly (ie. they are application-specific passwords, not internet passwords) since they would be of no use to other browsers anyway. I haven't implemented the generic password interfaces yet but it would be easy to do so.

(In reply to comment #73) > co-ordinate with Mossop and josh in #developers or #fx-team I joined irc://irc.mozilla.org/#developers and irc://irc.mozilla.org/#fx-team manually (my IRC client didn't find the rooms indexed). Topics make no reference to logs. Please, does anyone know, is either one logged anywhere?

Please: assume multiple keychains. (In reply to comment #75) > play nicely with the MacOS Keychain Passwords may be spread across *multiple* keychains. (Echoing and building upon comment #21) > Benefits to proper keychain integration on Mac OS X include: > * It's possible to store some items in non-login keychains that have their > own passwords. … not merely possible; it's sometimes *necessary* to keep items separate from the login keychain. Consider a job share in which a keychain for a role, or for a function, is passed from one person to another; and each person may have multiple roles. My own use case currently involves nine keychains -- some personal (two of three identities relate to troubleshooting Microsoft Exchange services), some functional. Other people's use cases will differ. > * Using keychains at a fine-grained level enables overall better integration > with the Mac OS X platform and other keychain aware applications and tools > in a way that just storing the master password cannot. Wishing support for multiple keychains should not block this enhancement bug 106400, but it should be a long-term consideration. --- > irc://irc.mozilla.org/#developers and irc://irc.mozilla.org/#fx-team > … is either one logged anywhere? In #developers I'm advised that there's no logging, but that Mossop and josh both are online frequently. --- A personal perspective: http://www.brighton.ac.uk/centrim/Members/gjp4/2009/08/06

(In reply to comment #76) > … Safari/Camino/etc. interoperability is the whole point of this bug. +1 to that and if it helps, http://www.diigo.com/06vy3 highlights a point from Apple's guide: >> Keychain services and other Mac OS X security APIs are built on the open source >> Common Data Security Architecture (CDSA) and its programming interface, >> Common Security Services Manager (CSSM). Apple refer to http://www.opengroup.org/security/cdsa.htm

Ugh, sorry, I meant: Dolske: who knows the password manager code in Firefox Josh: who knows about OSX integration work in Firefox, and might be able to hook you up with the best contact/reviewer there Apologies for the error.

I noticed the Chrome guys have looked into this, and have an interesting design document hilighting a number of issues with supporting Keychain... http://dev.chromium.org/developers/design-documents/os-x-password-manager-keychain-integration

Very interesting, thanks. For what it's worth, my analysis for the keychain services extension gave pretty much the same results and issues so I think this document is on track and very clearly written.

Another possibility not mentioned already is dual mode - Firefox will shadow copy between the two systems based on what it finds. Examples: 1. http://example.com (username) in exists only in Keychain. Firefox pulls the password and puts it in the form on the web page and then when the user submits it Firefox then adds it to the password manager as well. 2. http://foo.bar (myuser) exists only in FF password manager. The form is autofilled and on submit the password is copied into Keychain. 3. http://fairies.wand has no stored password. On submit the user is asked if they wish to store it. Upon choosing yes, the password is written to the Firefox password manager and then to keychain. Having a dual-system option will allow a user to keep their profile synchronized with the Firefox style for cross-platform portability and with Keychain for system interoperability. An additional field should be added to the FF password to indicate if it has been synced with keychain. A field should exist for each native platform password management system so that a FF profile need not step on the toes of another password manager. I think the dual mode would allow for fairly portable code as I am sure a generic "native" password API could be written to do all the heavy lifting. Some issues to solve: 1. What password is prioritized if it is different in both? (I vote the newer or inform the user of the conflict and let them choose). 2. If I had way better Objective-C skills I'd try my hand at this. :'( Other comments: I find that Firefox has the best password feild detector of all the browsers, but I don't use it as my primary Mac browser because in part the passwords are not portable to most of the other browsers for Mac OS X. That's all I got to say for now.

No progress at this issue? No progress on http://code.google.com/p/mozilla-keychain/ either (compatibility issue with FF 3.6.x)? Why not simply take Caminos code to use MacOSX' native keychain? Or why not simply take Google Chrome's code? Both browsers do have and use native MacOSX keychain integration. Be remembered to your own goals on https://wiki.mozilla.org/Firefox/Namoroka, Firefox.next Platform Requirements: System Integration * OSX Dictionary integration * OSX Services & AppleScript integration * OSX Keychain integration Also: https://wiki.mozilla.org/Firefox:Password_Manager No real progress on this bug since years and months, just vague declarations of intent...

Well... as far as the extension goes, I admit I haven't had much time of late to work on it, but I'm using it daily in 3.6.3 as are nearly 1000 other users so I think it's working ok. Honestly the major thing preventing me from doing the occasional bug fix is that I couldn't get the bloody thing to compile after upgrading to Snow Leopard. Last I tried, I couldn't find documentation of the required compile flags, spent hours on it, and then gave up. If anyone can give me the magic incantation to get a universal binary extension (or even a number of binaries) that works on intel/ppc, 10.6, 10.5 (10.4?), and in Firefox 3.6.x (and 3.5.x ?), I might well be inclined to close a few of the minor issues. :)

Another, simpler approach would be to generate a new password in cases where the user doesn't have a master password set for a given profile. Store that in Keychains and use it as the master password. This has two downsides obviously: a) you don't get login integration with other apps (do the extend that would actually work anyway) b) risk of orphaning all their saved password data if the user moves their profile or nukes the keychain entry.

Downside b) is a known and accepted risk of anyone using the OS X keychain. If storing the master password in the keychain is easier to implement, I'd certainly welcome it while we wait for full integration.

(In reply to comment #88) > Another, simpler approach would be to generate a new password in cases where > the user doesn't have a master password set for a given profile. Store that in > Keychains and use it as the master password. I filed bug 496660 on that approach a while back.

This bug was opened on 23-10-2001 — over 12 years ago. It has become blindingly obvious that not only has nothing has been done in this regard other than hand-wringing and -waving, but also that nothing is likely to ever be done. As a result, people CC'd on this should just bite the bullet and install the Keychain Services Integration add-on: https://addons.mozilla.org/en-us/firefox/addon/keychain-services-integration/ Shame on the Mozilla developers for not using the OS X Keychain after all these years, or at the very least optionally allowing its use.

They removed Growl support, which was platform specific and would have added support for Notification Center if they had updated the framework. I do not see them adding this in if they are getting away from platform specific items. Both items are unfortunate because they would make Firefox a better browser to have some native support for things on specific platforms. But it entirely depends on the goals that Mozilla has for Firefox going forward as to what they decide to do with this one. I'd just like to see it either get some progress or get closed with an explanation at this point (an explanation which is not "cleaning up tickets because this is really old ideally :) That said, I do not see any patches on this bug which are recent. I believe if a patch were made then perhaps this would have a better chance of being added in. No need to be negative about this though, that doesn't get things done. So, does anyone subscribed to this bug have the ability to get a patch written for this? If so let's get the ball rolling.

Emphasis on "lowest common denominator": http://www.apple.com/hotnews/thoughts-on-flash/ He was even more right than he knew at the time. This (pwmgr) is one reason I no longer use (or recommend) Firefox as my default browser. (As an aside: Big fan of your [plural] work, Chris. Keep it up.)

As I understand it, replacing the built-in login storage will no longer be possible under WebExtensions, so how about reviving this bug and bumping up the priority?

How exactly do we intent to make people switch to Firefox 57 when their passwords saved in the system's keychain won't be usable from Firefox?

(In reply to Anthony Ramine [:nox] from comment #97) > How exactly do we intent to make people switch to Firefox 57 when their > passwords saved in the system's keychain won't be usable from Firefox? +1 I have to stick with Firefox 56 to be able to use Julian Fitzell's Keychain Services Integration extension (https://addons.mozilla.org/en-US/firefox/addon/keychain-services-integration/, https://github.com/jfitzell/mozilla-keychain/) based on the old XUL API, which is essential for my day-to-day work or have to switch to another browser on the macOS platform which provides native support to macOS' keychain. See also: Issue 88: Extension will need to be ported from XUL by FF 57 https://github.com/jfitzell/mozilla-keychain/issues/88 Bug 1362981: Request WebExtensions API equivalent to nsiLoginManager https://bugzilla.mozilla.org/show_bug.cgi?id=1362981 Bug 1344788: Implement login storage API https://bugzilla.mozilla.org/show_bug.cgi?id=1344788 Please finally provide a webextension API so that an apropriate web extension could be build to use macOS' keychain. Or better: finally provide _native_ support for macOS' keychain in Firefox 56+ (means: asap) so that a browser extension to fill this very gap is obsolete. It's time. It's meanwhile (after years of letting things slide) very urgent. Or this years old gap is a further one to drive once faithful Firefox users on the macOS platform into the arms of the competition (which provides such access to the system's build in keychain, natively, long ago).

[Tracking Requested - why for this release]:

I don't think this is in scope for 57.

Just another voice on this: Although I would prefer Firefox over any other browser, this is the #1 reason for me not using Firefox on macOS anymore. With browsers fighting for every percent of the market share, I can only shake my head why Mozilla developers don't realize that implementing this (tiny) feature has great effect on the acceptance on macOS.

(In reply to jd_mozilla from comment #101) > Just another voice on this: > > Although I would prefer Firefox over any other browser, this is the #1 > reason for me not using Firefox on macOS anymore. > With browsers fighting for every percent of the market share, I can only > shake my head why Mozilla developers don't realize that implementing this > (tiny) feature has great effect on the acceptance on macOS. +1 (!)

(In reply to Sierk Bornemann from comment #102) > (In reply to jd_mozilla from comment #101) > > Just another voice on this: > > > > Although I would prefer Firefox over any other browser, this is the #1 > > reason for me not using Firefox on macOS anymore. > > With browsers fighting for every percent of the market share, I can only > > shake my head why Mozilla developers don't realize that implementing this > > (tiny) feature has great effect on the acceptance on macOS. > > +1 (!) Another +1 from me. If native Keychain integration can't be included then provide the API for a WebExtension. As others have noted, otherwise means maintaining two sets of credentials for every website for Mac users using more than one browser in their day-to-day work.

(In reply to oneofthedamons from comment #103) > As others have noted, otherwise means > maintaining two sets of credentials for every website for Mac users using > more than one browser in their day-to-day work. I'm curious, are there any important browsers left that actually support this? It's been quite a while since Firefox, Safari, and Chrome were able to properly share credentials via the Keychain. Chrome has removed support entirely. Safari can at most read items saved by Firefox – any changes will be saved as new items in the iCloud Keychain, where they remain inaccessible to other applications. I have previously advocated for this bug and opened bug 1344788 for a few reasons: 1. I have always found third-party password managers awkward in how they integrate with the browser. 2. While Apple's Keychain Access utility isn't great, it's better than nothing. Firefox by itself offers no password management capabilities. 3. I've been holding on to a hope that Apple would ease up on the restrictions with the iCloud keychain and specify some kind of scheme for both desktop and mobile browsers to share credentials with one another. However, in all honesty I don't see #3 happening in the near term, if ever. And after trying out the current version of 1Password, concerns #1 and #2 no longer apply (for me, at least). The UI is pretty great, it integrates well, and for password management tasks an actual password manager is obviously on another level compared to the Keychain utility. So, personally, I no longer consider this an important feature, unless Apple changes its policy about the iCloud keychain and other browser vendors follow suit. The only benefit we would currently get from replacing Firefox's built-in password storage with the Keychain is rudimentary password management functionality. As long as this is the case, people might find better success advocating for that functionality to be integrated into Firefox preferences, where it would be available to everyone, not just Mac users.

(In reply to bintoro from comment #104) > (In reply to oneofthedamons from comment #103) > > As others have noted, otherwise means > > maintaining two sets of credentials for every website for Mac users using > > more than one browser in their day-to-day work. > > I'm curious, are there any important browsers left that actually support > this? > > It's been quite a while since Firefox, Safari, and Chrome were able to > properly share credentials via the Keychain. Chrome has removed support > entirely. Safari can at most read items saved by Firefox – any changes will > be saved as new items in the iCloud Keychain, where they remain inaccessible > to other applications. It is not necessarily only about having an account's credentials being shared by several applications. If one already has all credentials of a kind stored in one place (e.g. the macOS keychain), storing them over again in a different place (e.g. Firefox's password storage) likely increases the attack surface compared to duplicating them in the initial secure storage. > And after trying out the current version of 1Password, concerns #1 and #2 no > longer apply (for me, at least). The UI is pretty great, it integrates well, > and for password management tasks an actual password manager is obviously on > another level compared to the Keychain utility. The keychain is good enough for some. Being expected to pay a fee when you feel that what you have is good enough is off-putting; and even for free alternatives, the cost of adapting (to a different UI, workflow, etc.) can be a hard sell, whatever the benefits.

(In reply to Gonzalo HIGUERA DÍAZ from comment #105) > It is not necessarily only about having an account's credentials being > shared by several applications. Right, but that was the argument put forward in comment #103. I would really like to know what kind of useful cross-browser functionality the guy is getting out of the Keychain, because I'm not getting any. > If one already has all credentials of a kind > stored in one place (e.g. the macOS keychain), storing them over again in a > different place (e.g. Firefox's password storage) likely increases the > attack surface compared to duplicating them in the initial secure storage. True. One advantage of the Keychain system is that it allows you to store the most sensitive logins in a separate keychain that is auto-locked after a short while. That said, I stand by my analysis that proposals to improve the built-in password storage are likely to resonate better with Mozilla than this bug. This one's been open for 16 years. If Mozilla didn't see the Keychain as a priority back when it was vastly more useful than today, they are unlikely too see it as a priority now.

(In reply to bintoro from comment #106) > (In reply to Gonzalo HIGUERA DÍAZ from comment #105) > > It is not necessarily only about having an account's credentials being > > shared by several applications. > > Right, but that was the argument put forward in comment #103. I would really > like to know what kind of useful cross-browser functionality the guy is > getting out of the Keychain, because I'm not getting any. [snip] I'm "the guy" who submitted #103 – thanks for responding! I've used Safari and Firefox interchangeably in the past. The shared keychain using https://addons.mozilla.org/en-US/firefox/addon/keychain-services-integration/ made this easier. Looks like FF57 won't support the functionality required by that extension. From what I can gather it's partly Apple and partly Mozilla. Like most interoperability problems! I like the MacOS keychain. I don't use password managers, and Keychain.app provides more functionality than that inbuilt into Firefox. But it may be I'm just an odd duck. Again, thanks for responding, and happy to answer any further queries.

Actually, there is more with keychain integration than just storing passwords. While there are meanwhile other solutions (like 1password, etc.) that allow credential sharing across browsers and even hosts, there is another important use case (for me) that isn't covered yet. That is certificate management. Currently, I need to manage all certificates in two different places, keychain and firefox. Basically all other applications use the keychain for certificate storage and validation. It's only firefox that handles that in his own storage. Not sure if that use case is covered by the initial request here, but it may give another perspective on the issue.

(In reply to oneofthedamons from comment #107) > I've used Safari and Firefox interchangeably in the past. The shared > keychain using > https://addons.mozilla.org/en-US/firefox/addon/keychain-services-integration/ > made this easier. In the past, yes, but hasn't this been broken for years now? Ever since the introduction of iCloud Keychain, any credentials saved by Safari have ended up there (or its offline equivalent called Local Items), making them inaccessible to Firefox or any other application. The extension doesn't create any sort of "shared keychain". > Looks like FF57 won't support the functionality required by that extension. > From what I can gather it's partly Apple and partly Mozilla. Like most > interoperability problems! I think any fix to this has to start with Apple. In fact, I have a Radar issue filed with them about it. The fundamental problem is that the iCloud Keychain doesn't support ACLs like traditional keychains. Items in the iCloud Keychain can only be shared among a group of apps from the same vendor. https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html#//apple_ref/doc/uid/TP30000897-CH204-SW11 It doesn't seem like a huge leap to implement some kind of mechanism for cooperative apps from different vendors to share credentials, but AFAIK it's just not possible right now. So, while there may be some arguments in favor of Keychain support in Firefox, browser interoperability isn't currently one of them. Even if the iCloud Keychain allowed password sharing per se, there's still the problem of multiple browser profiles. Chrome used to have working Keychain support but abandoned it for precisely these reasons. > I like the MacOS keychain. I don't use password managers, and Keychain.app > provides more functionality than that inbuilt into Firefox. It does, but I'm afraid it's not enough for this bug to go anywhere. Let's face it, the Keychain Access utility is simply not suited as a password manager for your average user, and it downright sucks at any sort of bulk operations.

Hey, I'm back commenting on this after 8 years (see comment #85)! I still think that platform native password managers should be supported if for no other reason than to give users the choice on how their passwords are managed. I think the Chrome people made the wrong decision cutting Keychain out entirely instead of making it optional. Thus I still think that Keychain in this case should be supported as an option for the password manager. Let anyone who wants to deal with the intricacies of copying items from iCloud Keychain to the local do so, that shouldn't be your concern. I think that this project's concern should be with implementing the feature and lobbying Apple to allow access to iCloud Keychain. Users who elect to use Keychain should be presented with a notice like this in the Firefox preferences: > Note: Applications distributed outside of the macOS App Store such as Firefox can only access the local Keychains, not the iCloud Keychain." That's all I got for now. See you again in another 8 years?

This feature is not particular about password sharing. This feature is to store passwords into the only safe place in macOS that has especially be created for apps to store passwords and that pretty much any macOS app uses: The keychain. So it's not about iCloud keychain or not iCloud keychain, ACLs or no ACLs, it's about the inability to implement a simple platform feature that would probably require something around 200 to 400 lines of code, extremely simple code, and that should have been added 15 years ago. Storing passwords in a file cannot be safe, a root user (and thus every admin user knowing sudo) can get access to this file. Encrypting it is not safe either, as the decryption password is either always the same and in the code (pretty bad idea for OpenSource software) or it must be randomly generated but then it must be stored in a file and again, the root user will have access to this file. So I cannot even protect my passwords from snooping by other users of the system, and as all this happens with my user ID, I cannot protect my data from being stolen by Malware either, which won't even need root permissions, it's enough if it runs with my user ID. But a root user cannot access my keychain on macOS and Malware cannot access my keychain on macOS (at least not the passwords)! And when you are already at it, it would be nice if Fx would also look for trusted CAs in keychain, as currently when installing a company CA, then all TLS connections using any certs signed by these CAs will be automatically trusted and everything works smoothly for Mac users, unless they want to use Fx, which will throw very disturbing warning about insecure connections, that these users don't understand, they don't understand what they did wrong and they don't understand how to fix it. Yeah, different issue, but in the end it's the same API as CAs are also stored in keychain on macOS.

Normally i'm on the beta channel but since the "Keychain Services Integration" add-on ceased to work with 57 i had to drop back to 56. Firefox just doesn't work for me without proper access to saved passwords. I just have too many and need them across multiple browsers for development purposes.

Must have feature. Only reason i didn't stop using firefox was the of the (3rd party) keychain integration extension. If there is no native support for the macOS-keyhcian or by 3rd party addon, i will stop using firefox. The Keyhcain ist a must have for good software on apple systems.

This is a show-stopping barrier for me and many others. As much as I love the new improvements to Firefox, I have hundreds of passwords managed by the icloud keychain already that I use across Safari on multiple devices, and even across apps on my phone. I simply must revert to Safari until this issue is addressed.

(In reply to mathgraph from comment #114) > I have hundreds of passwords managed by the > icloud keychain already that I use across Safari on multiple devices, and > even across apps on my phone. I simply must revert to Safari until this > issue is addressed. Are you saying you're somehow still able to access Safari passwords from within Firefox? I thought this stopped working with the advent of iCloud Keychain, which placed Safari credentials out of reach of other apps.

(In reply to bintoro from comment #115) > (In reply to mathgraph from comment #114) > > I have hundreds of passwords managed by the > > icloud keychain already that I use across Safari on multiple devices, and > > even across apps on my phone. I simply must revert to Safari until this > > issue is addressed. > > Are you saying you're somehow still able to access Safari passwords from > within Firefox? I thought this stopped working with the advent of iCloud > Keychain, which placed Safari credentials out of reach of other apps. No, that's the point, is that it doesn't work in Firefox. At the very least I would expect Firefox to support local keychains (something supported by https://addons.mozilla.org/en-US/firefox/addon/keychain-services-integration/ and apparently no longer possible in the latest versions of Firefox), and a user could export their iCloud keychain to a local keychain for use with Firefox. I'm open to varying and creative solutions to get around limitations of the platform, but the fact remains that having all my passwords stored in the iCloud keychain with no way to access them from Firefox is a significant barrier enough to preclude me (and others) from ever using Firefox unless some path forward is implemented (using direct sharing, export/import, helper app distributed on the app store that can be a bridge between Firefox and iCloud keychain, or some other clever idea).

(In reply to bintoro from comment #115) > (In reply to mathgraph from comment #114) > > I have hundreds of passwords managed by the > > icloud keychain already that I use across Safari on multiple devices, and > > even across apps on my phone. I simply must revert to Safari until this > > issue is addressed. > > Are you saying you're somehow still able to access Safari passwords from > within Firefox? I thought this stopped working with the advent of iCloud > Keychain, which placed Safari credentials out of reach of other apps. Not only can I still access passwords, I can still create new entries in the MacOS 10.12 Keychain using FF56 and Keychain Services Integration extension. Just confirmed this with a brand new site for which I've never created an account until now. This still works perfectly well for me. Disappointed this functionality is being removed from FF57. Like others, I suspect it's over to Safari now for me too :-(

Just want to add a new perspective to the voices: implementing native Keychain access (or taking as many steps in that direction that Apple permits) would add another differentiating factor that Chrome wouldn't do. Google has too much momentum behind 'owning' their users to ever take this step. Fighting for users and their interests can really be a strong way to draw attention and bring in/back users. Similar to how Safari is capitalizing on their new 3rd party tracking blocking, as a way to draw the most contrast possible with the browser built by a third-party advertising/tracking company. In case it's not clear to everyone, the killer feature of Keychain that hasn't been too explicitly mentioned is that the native iOS keyboard now has access to the passwords so that the same password can be used in apps as well as their web counterpart. I realize some apps have interop with password managers, but the native approach doesn't require much if any from the app to work (I believe simply using proper field designations is sufficient). I am very excited about returning to Firefox full time once this barrier is removed, but it will have to be my secondary until then. Thanks to everyone for all the work on Quantum.

As others have said, the lack of an integration with Macos's builtin keychain makes Firefox a no-go for people switching from Safari, especially if they take advantage of its integration with iOS. After the release of FF57 I gave it a shot and so far the _only_ lacking feature is having to copy and paste all of my - generated, for the most part - passwords from the Keychain Access application. I can access keychain passwords from applications on iOS, many applications on desktop, on mobile Safari, and on desktop Safari, which is extremely convenient. I would love to return to Firefox with its new improvements after years of using Safari, but with the lack of a keychain integration or support for the keychain integration add-on, it's become a no-go for daily use for me.

This ticket seems to conflate two different features: keychain integration, and iCloud keychain integration. I don't personally use the iCloud one, but it would be really helpful to me if at least Firefox could access Internet passwords from the local default keychain. AFAIK *that* is allowed with the current macOS API.

(In reply to MeIr from comment #121) > I can't upgrade to Firefox Quantum because of this and I > wonder perhaps it is time to move to Chrome, where keychain integration is > done out of the box. No it’s not. You can read all about it here: https://bugs.chromium.org/p/chromium/issues/detail?id=466638

(In reply to bintoro from comment #122) > (In reply to MeIr from comment #121) > > No it’s not. You can read all about it here: > https://bugs.chromium.org/p/chromium/issues/detail?id=466638 Despite that, Chrome still has Keychain integration for certificates! By now, that has (for me) even more importance than storing passwords as other sync apps have taken care of that by now. Use case: Custom CA certificates as well as personal certificates for X.509 authentication can be stored at a single location, shared by all browsers (except Firefox!) and even synchronized with other hosts (not via iCloud).

Last month, I switched back to Firefox after 2-3 years of using Safari, missing the awesome bar and tree-style tabs, with the Keychain integration extension [1] being the essential thing I needed to keep my logins in sync with my iOS devices and my desktop browser. Very disappointed to see this broken with Firefox 57, just a few weeks later! It would be great if the team could look into building out the APIs needed to support this extension. I think this GitHub comment has a comprehensive list: https://github.com/jfitzell/mozilla-keychain/issues/88#issuecomment-332331685 [1]: https://addons.mozilla.org/en-US/firefox/addon/keychain-services-integration/?src=api

We understood your comments & arguments but repeating them are not helping. I will restrict the comments to people who have editbugs permissions. If you want to contribute, don't hesitate to contact me by email.

At this point, given the changes Apple has made regarding iCloud Keychain, and that Chrome has moved away from storing in Keychain, I wouldn't take a patch to implement this as it would be a significant cost with per-platform support and it would require augmenting the data in Keychain to provide additional metadata needed by Firefox for little value. Extension APIs (which I know aren't yet available) would be the solution for implementing this if there is enough demand.