Integrate with Gnome Keyring

[Danilo Piazzalunga]

For a really good Gnome integration, it would be great to have the ability to save passwords in the Gnome keyring.

A similar thing has been proposed for Epiphany: see https://launchpad.net/malone/bugs/3467.

[Marius Scurtescu (marius-scurtescu)]

Camino is doing exactly this, a similar implementation could be used.

[Martin Meyer (elreydetodo)]

I like the idea of integrating the password manager with Gnome, but is it possible to make it so that any password manager application could be made to plug into Firefox's password management system? It would be nice to use Norton Password Manager on Windows, or whatever comercial program the user happens to like and have Firefox use it directly. This would be a good thing for integration with operating environments and other applications.

[Danilo Piazzalunga (danilopiazza)]

For a really good Gnome integration, it would be great to have the ability to save passwords in the Gnome keyring.

A similar thing has been proposed for Epiphany: see https://launchpad.net/malone/bugs/3467.

[Dolske (dolske)]

Now that the Login Manager rewrite has landed on trunk for Firefox 3, writing a module to implement this support should be much easier. Basically, someone needs to write a component implementing the nsILoginManagerStorage interfaces, and that component would interact with the Gnome Keyring as needed.

This interface is described here: http://mxr.mozilla.org/seamonkey/source/toolkit/components/passwordmgr/public/nsILoginManagerStorage.idl

This task isn't currently on my to-do list, but I'd be happy to help explain the Login Manager interaction if someone wants to take a shot at this.

[Sylvain Pasche (sylvain-pasche)]

One potential issue I'm seeing is that nsILoginManagerStorage makes synchronous requests, which will freeze the UI while Gnome Keyring is asking for the password.

I'm not completely sure, but I also have the feeling the OS X Keychain API blocks the calling thread while waiting for the password (SecKeychainFindInternetPassword). That would mean the same issue happens for the OS X implementation.

[Sylvain Pasche (sylvain-pasche)]

I'm going to work on this, feel free to contact me if you want to help.

[Sylvain Pasche (sylvain-pasche)]

Created an attachment (id=270527)
version 0.1

First version. There are some issues when used with the password manager, like asking to save password more that necessary, or not updating password if changed.

See the XXX for other things to improve. There is no caching involved, so there are round-trips to the gnome-keyring-daemon for every page containing a form, which could be bad for performances.

I can confirm the issue where the UI is frozen in case gnome-keyring daemon is asking for confirmation. I saw that this is also happening with Camino+Keychain, but that's less an issue on OS X as the window content is buffered, unlike on X11 where it is not refreshed if we move another window above (ok, that should not be the case when using a compositing window manager).

[Sylvain Pasche (sylvain-pasche)]

Created an attachment (id=270611)
version 0.2

Forgot to unregister the category, and fixed an unused variable warning.

[Sylvain Pasche (sylvain-pasche)]

This went low priority for me, feel free to take this over.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

The correct link for the corresponding Epiphany bug is now https://bugs.launchpad.net/epiphany/+bug/3467.

[Dtownsend (dtownsend)]

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

[Jakub 'Livio' Rusinek (liviopl-pl)]

Does GNOME keyring replace Firefox internal password manager?
If not, it should.

[Sylvain Pasche (sylvain-pasche)]

(In reply to comment #10)
> Does GNOME keyring replace Firefox internal password manager?

no

> If not, it should.

That's what this bug is about, but no one is working on it right now.

[Jakub 'Livio' Rusinek (liviopl-pl)]

Exactly the same situation with some non-duped bugs I've filed.

[Dan-500 (dan-500)]

This bug is not only firefox related. It's a core bug.

[Sylvain Pasche (sylvain-pasche)]

I agree, it should rather be toolkit related (password manager is in toolkit/components/passwordmgr), but there's no Toolkit/Password Manager component.

[Dolske (dolske)]

There's been much discussion on reorganizing Bugzilla (eg, the thread rooted at http://groups.google.com/group/mozilla.dev.planning/msg/5c973137356768b0). It's been deferred for a variety of reasons, but should eventually happen. In the meantime, it's understood that a number of components in Firefox are effectively in Toolkit, so it's not really an issue. [The code is, in fact, in /toolkit.]

[Me-at-work (me-at-work)]

(In reply to comment #1)
> Camino is doing exactly this, a similar implementation could be used.
>

That's a different bug, the mac only bug 106400.

[Nikolaus Rath (nikratio)]

Confirming, this would indeed be a nice feature.

[Alexander Sack (asac)]

On Sun, Apr 27, 2008 at 07:57:22AM -0000, Nikolaus Rath wrote:
> Confirming, this would indeed be a nice feature.
>
> ** Changed in: firefox (Ubuntu)
> Status: Incomplete => Confirmed
>

ffox 2 won't see any fixes in this direction anymore

 affects ubuntu/firefox
 status wontfix

ffox 3 neither as since ffox 3 the code that deals with this is
shipped by xulrunner 1.9

 affects ubuntu/firefox-3.0
 status invalid
 affects ubuntu/xulrunner-1.9
 status confirmed
 importance wishlist

 - Alexander

[Dolske (dolske)]

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

[Michael Nagel (nailor)]

I'd be very delighted to see this functionality. And as I am a GNOME user this would fix things quite nicely. However some people use KDE and even cruder stuff... They'd like to have support for kwallet or some other keyring manager... I'd like to change this bug to a more generic description.

... and then there is bug #75850 that is just the same bug as this one only that it is filed against pidgin ...

And I begin to wonder if there is not any standard abstract infrastructure for managing passwords. I think there are quite some applications that could make use of a proper password manager...

So to be more precise:
a) do we have a desktop environment independent password management infrastructure?
b) should we have one?
c) should theses bugs be kept separate or should they be united?

[Alexander Sack (asac)]

On Fri, Jun 27, 2008 at 02:56:09PM -0000, Michael Nagel wrote:
> I'd be very delighted to see this functionality. And as I am a GNOME
> user this would fix things quite nicely. However some people use KDE and
> even cruder stuff... They'd like to have support for kwallet or some
> other keyring manager... I'd like to change this bug to a more generic
> description.
>
> ... and then there is bug #75850 that is just the same bug as this one
> only that it is filed against pidgin ...
>
> And I begin to wonder if there is not any standard abstract
> infrastructure for managing passwords. I think there are quite some
> applications that could make use of a proper password manager...
>
> So to be more precise:
> a) do we have a desktop environment independent password management infrastructure?
> b) should we have one?
> c) should theses bugs be kept separate or should they be united?
>

Please dont make this bug more generic. Its about gnome keyring. if
you want something more generic, open a new bug or open individual
bugs for other keyring APIs.

 - Alexander

[Matt Lavin (matt-lavin)]

Created an attachment (id=336264)
Updated patch to compile against firefox 3

I've modified the patch lightly to get it to compile on Firefox 3.

[Matt Lavin (matt-lavin)]

Created an attachment (id=336498)
Fixes for interaction with form login

While testing the latest path, I noticed that it didn't properly store and retrieve passwords saved in forms. I've attached an updated patch that works for me.

There are some more things that could be improved about the code, but what are the steps to get this included in Firefox proper?

[Jakub 'Livio' Rusinek (liviopl-pl)]

I have simple question: does this include migration?

[Matt Lavin (matt-lavin)]

The current code doesn't include any migration support.

[Matt Lavin (matt-lavin)]

I've uploaded an installable version of this extension to https://addons.mozilla.org/en-US/firefox/addon/8737 to enable more people to test out the integration. Hopefully, some people will be able to give some good feedback to improve it.

[Jensus (jensus)]

I've tried the extension.

When it's installed I'm unable to store passwords.
The prompt "Would you like firefox to remember this password" stays visible after I click on "save password". No passwords is added to my keyring.

How can I debug this?

[Matt Lavin (matt-lavin)]

What are you using to verify that the password was added to the keyring? If you return to the same page again, is the password automatically filled in? Are there any errors in the Tools -> Error Console page?

[Jensus (jensus)]

I get this exeption in the console:

Fel: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILoginManagerStorage.addLogin]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///usr/lib/xulrunner-1.9.0.1/components/nsLoginManager.js :: anonymous :: line 388" data: no]

The password I tried to add does not appear in firefox password list, nor in seahorse (g-k-m frontend).

Im using Ubuntu 8.04 with a keyring that is automatically unlocked on login.

[Sylvain Pasche (sylvain-pasche)]

(In reply to comment #19)
> There are some more things that could be improved about the code, but what are
> the steps to get this included in Firefox proper?

Hi Matt, thanks for your work on this. The steps would be to find someone to review this. There are instructions on http://developer.mozilla.org/en/Getting_your_patch_in_the_tree how to find the right reviewer.

Another more general question is to know if this should be part of Firefox or should live as an extension.

On a more technical side, is the issue raised in comment 4 still there? That would be nice to have it addressed (it may not be trivial, if the API has to change to get asynchronous).

I was a bit worried about performance (comment 6). It could be interesting to see how having the addon enabled can impact performance when browsing pages with passwords (https://wiki.mozilla.org/StandaloneTalos is one of the tool for measuring regressions). Caching could help if the performance is an issue.

The current patch implements nsILoginManagerStorage directly in C++. Another approach I thought about would be to wrap the low-level Gnome Keyring API in a C++ component and then implement nsILoginManagerStorage in JS. That should make things simpler for adding caching (if needed), managing preferences (keyring name is hardcoded right now for instance) or others. (https://wiki.mozilla.org/JSctypes could be useful here but I don't think it's ready yet)

[Dolske (dolske)]

I think I'd sort of like to see more experience with people using this as an extension, first. One of the things that I want to be cautious about is moving where we store things (mozStorage vs keyring/keychain) without compelling value... The pessimistic view here is that most users won't care, and it incurs code maintenance costs.

One variation that would also be interesting to pursue is leaving the password storage where it is now, but using the keyring/keychain for storing a decryption key (sort of like a master password). For users that don't want the annoyance of a master password (as we currently implement it), pulling a decryption key from a system DB that's secured with the user's *login credentials* would be an improvement.

[Matt Lavin (matt-lavin)]

(In reply to comment #25)
> I get this exeption in the console:

I've uploaded a new version of the extension that enables some logging to get extra information about your failure. You can see the extra logging by running firefox from a command line like "NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox -no-remote"

You should see a message or two like:
-1211177280[805ca10]: GK_ENSURE_SUCCESS(2) failed

In the console, and that will help us figure out why you can't safe passwords.

[Matt Lavin (matt-lavin)]

Thanks for all the feedback. I'll keep an eye on performance problems. About the screen repaint issue, I just got prompted to allow access to the keyring and Firefox had no problem repainting in the background.

I was personally motivated to fix get the gnome-keyring integration out there because I wanted to reduce the number of unencrypted passwords on my drive. Since that's my main goal, I don't mind if this feature lives as an extension or as part of the standard packaging as long as I can use it =).

As for the relative value of the keyring integration, it's all about security (although something like your suggestion would have worked as well). The argument that "that most users won't care" should really be re-phrased to say "that most users won't care, until they sell their machine and the buyer uses their passwords left on disk". Leveraging something like gnome-keyring to get the password encryption for free seemed like a easy win for me (and Sylvain had done most of the work already).

[Sylvain Pasche (sylvain-pasche)]

(In reply to comment #27)
> One variation that would also be interesting to pursue is leaving the password
> storage where it is now, but using the keyring/keychain for storing a
> decryption key (sort of like a master password). For users that don't want the
> annoyance of a master password (as we currently implement it), pulling a
> decryption key from a system DB that's secured with the user's *login
> credentials* would be an improvement.

That seems a good way to go. At the time, I started writing an extension to store the master password in the Gnome Keyring (however I didn't finish it). The idea was to have an option when setting the master password like "Generate and store Master Password in Keyring". Then a component would set it automatically during startup.

[Jensus (jensus)]

(In reply to comment #28)
> You can see the extra logging by running
 firefox from a command line like "NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox
> -no-remote"
>
> You should see a message or two like:
> -1211177280[805ca10]: GK_ENSURE_SUCCESS(2) failed
>
> In the console, and that will help us figure out why you can't safe passwords.

I just tried this on another computer and it worked without any errors.
However, the passwords are only visible in firefox, not seahorse. Is that correct?

[Matt Lavin (matt-lavin)]

(In reply to comment #31)
> However, the passwords are only visible in firefox, not seahorse. Is that
> correct?

That's because the passwords are stored in the 'default' keyring, and not the 'login' keyring. Apparently, Seahorse only shows the passwords in the 'login' keyring.

[Jensus (jensus)]

(In reply to comment #32)
> (In reply to comment #31)
> > However, the passwords are only visible in firefox, not seahorse. Is that
> > correct?
>
> That's because the passwords are stored in the 'default' keyring, and not the
> 'login' keyring. Apparently, Seahorse only shows the passwords in the 'login'
> keyring.

Ah, I see!

The entry may look nicer to the user in the sehorse password listing if the type GNOME_KEYRING_ITEM_NETWORK_PASSWORD is used. Also, the display name is currently set to "Mozilla keyring entry". It should probably be the url, or something like "User at http://hostname..."

[Devel-leo-von-klenze (devel-leo-von-klenze)]

Hello!

I've downloaded the patch and compiled it successfully under my 64-bit Ubuntu. After installation the extension is displayed by firefox as active extension.

I used the command from comment #28 but I don't see any log messages that might belong to the gnome keyring extension. The passwords are saved but I think they are saved by the firefox password manager, because I can't see them in seahorse, even after setting the keyring to 'login'.

Missed I something?
Thanks!

[Legolas558-users (legolas558-users)]

This feature is a win-win! How long should it take before I can see it as an extension?

Thanks

[Sylvain Pasche (sylvain-pasche)]

(In reply to comment #35)
> This feature is a win-win! How long should it take before I can see it as an
> extension?

Not very long: https://addons.mozilla.org/en-US/firefox/addon/8737 (see comment 22)

[sekh (wlallemand)]

Hello !
I've installed the last 0.2 firefox plugin.
That doesn't seem to work.
I'm using firefox 3.0.5 on ubuntu 8.10.

 NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox -no-remote
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed

Gnome doesn't ask me to authorize firefox to use gnome-keyring.
When I click on "Add Password" on the bar, that do nothing, I have to click on "never" or "not now" for see the bar disappear.

[Jze (jze)]

(In reply to comment #37)
> -1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed
>
Error code 4 means "no such keyring". The add-on uses the keyring "default" instead of Gnome's default keyring "login". You can create a new keyring using Gnome's seahorse program.

[Luis Carlos Cobo (luiscarlos)]

Looks like someone has been working on an add-on for this:

https://addons.mozilla.org/en-US/firefox/addon/8737

Unfortunately, it does not seem to work for anyone.

[mescalinum (mescalinum)]

the firefox addon doesn't work for Linux64

[Jensus (jensus)]

Unfortunately, this extension does not play well with xmarks bookmarks and password synchronization extension (http://www.xmarks.com).

If I install this extension after having used xmarks for a while, no stored passwords shows up and the master password for xmarks is gone.

[Jordan Erickson (lns)]

I've been wanting gnome-keyring support for Firefox/Thunderbird/Sunbird for some time now. Is there no common password handling libraries for these Mozilla projects that would make it easier, at least for the Mozilla side, to implement?

[John Vivirito (gnomefreak)]

Is this going to be implemented in Xulrunner or in an extension? I would like to not have to add extension to make this work. I dont use too many extensions but i know people with 10+ installed adn the risk of crashes is fairly high at that point adding another isnt the best way to fix this IMHO

[John Vivirito (gnomefreak)]

@Jordan: this is being worked on upstream on xulrunner. We want to let them implement this.

[Jordan Erickson (lns)]

John, thanks for the info. Is there a bug report for xulrunner that you know of which we can attach this one to?

[Ciro-scognamiglio (ciro-scognamiglio)]

Created an attachment (id=388144)
Tarball to be extracted in mozilla source directory

Hi,
I tried to iron away some problems with the extension:
* I set it to use its own keyring, named mozilla. Since items' attributes are tailored to fit mozilla login manager, it seems to me this makes more sense than cluttering the default keyring. This way, one can also decide whether to unlock it on log in or not independently from the default keyring.
* Most importantly, I made the component create the keyring if it doesn't exist.
I think this should make it work for most of the people that were unable to save passwords.
* The item name is now the hostname for which the password is saved (makes more sense than "Mozilla keyring entry" for every item)
* I took the liberty to add Matt Lavin and myself to the contributors.

These are the most prominent issues that I feel should be addressed next:
* The component still builds with the mozilla build sistem, I'd like to make it a separate extension but I don't know how to do it...
* I still have to move to firefox 3.5, I don't know if it works with it.
* It would be very nice to be able to migrate logins from and back to the built-in login manager, maybe prompting the user whether they want to delete logins from the unused login manager.
* Even when using gnome-keyring as login manager, you still get asked for the master password if you want to see the passwords on the "saved passwords" window. This only happens if the master password is set. I think this is firefox's fault.

By now, what I think is most important is to build it as an extension and to make it compatible with firefox 3.5
Help is appreciated...

[Ciro-scognamiglio (ciro-scognamiglio)]

Created an attachment (id=389136)
New verson for firefox 3.5

This is the new version for firefox 3.5, it doesn't work for firefox 3.0 because the interface has changed.
I plan to build an extension out of it and upload it on amo in the next days.

[Matt Lavin (matt-lavin)]

Created an attachment (id=389159)
Firefox 3.5 extension packaged for building outside of Firefox source tree

Thanks for the updates to support 3.5. Sometime during the 3.5 cycle I made changes to my local files to support building outside of the Firefox development tree. I've attached a version of that build environment that includes your fixes. That should allow easier building of the extension by other people.

[Ciro-scognamiglio (ciro-scognamiglio)]

Created an attachment (id=389337)
Makes keyring name customizable, fixes some possible leaks

The Makefile provided by Matt works perfectly, just note that if you compile for amd64 you need to add -fPIC to CPPFLAGS and put /Linux_x86_amd64-gcc3 everywhere you read Linux_x86-gcc3.
This new version makes keyring name customizable, you need to create a string preference entry named extensions.gnome-keyring.keyringName to change it.
Note that logins you've already saved will still be used, because gnome-keyring searches through all unlocked keyrings, not just the one we're using.

[Matt Lavin (matt-lavin)]

I just started a github project that holds my source tree. I've added the changes from luca in comment 44, along with adding the -fPIC compile flag by default.

The github URL is http://github.com/mdlavin/firefox-gnome-keyring/tree/master. If somebody would like to make the Makefile more flexible to handle the "Linux_x86_amd64-gcc3" / "Linux_x86-gcc3" changes automatically, that would be great.

[Jonathan Rogers (jonner)]

I just tried https://addons.mozilla.org/en-US/firefox/addon/8737 on Firefox 3.5.3 on Jaunty amd64 and it works great. It seems to be if it were installed by default, it would solve the problem quite well.

[John Vivirito (gnomefreak)]

On 10/12/2009 04:19 PM, Jonathan Rogers wrote:
> I just tried https://addons.mozilla.org/en-US/firefox/addon/8737 on
> Firefox 3.5.3 on Jaunty amd64 and it works great. It seems to be if it
> were installed by default, it would solve the problem quite well.
>
we could package the extension for Ubuntu (not install by
default) but i would rather Mozilla to fix this upstream.
Having upstream fix this is something that would be best since
extensions tend to update too much and can cause breakage with
browser.

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[Guillermoadrianmolina (guillermoadrianmolina)]

Hello, I've created a new extension based on this one. It is useful to connect to kde's kwallet. My questions are:
Am I violating any license issue?, in other words, am i allowed to create a new extension based on this one?
Where do I commit this extension?, should I use https://addons.mozilla.org/ ? or as a new bug request here?

Thanks in advance.

[Jesse Glick (jesse-glick)]

(In reply to comment #27)
> leav[e] the password storage where it is now, but us[e] the keyring/keychain
> for storing a decryption key (sort of like a master password)

Agreed. I would rather have such an option than the current extension, even if it added a password migration feature (the lack of which prevents usage for someone like me with hundreds of entries). The built-in password manager is fine except for the need to type in a master password every session. Is there any interface for an extension to replace just the "Enter Master Password" dialog?

[Paul-oshannessy (paul-oshannessy)]

(In reply to comment #47)
I filed bug 496660 (essentially what Dolske proposed in comment #27) a while ago. That's OSX specific, but no implementation is done. There's some work being done in other bugs to separate out the dependence on the master password as is.

[Oleksij Rempel (olerem)]

Looks like this plugin do not working for me. Installed, but password are stored to mozilla storage - not to gnome-keyring.

[Oleksij Rempel (olerem)]

This plugin do not working for me on karmic/amd64 :(

[Micah Gersten (micahg)]

Xulrunner 1.9 is only receiving Security Updates and major bug fixes at this point.

[Micah Gersten (micahg)]

Let's track this on xul-1.9.1 as it's the best place at the moment.

[Florian Haas (fghaas)]

Is there an update on getting this extension packaged for Lucid? I (and I suppose others) would be reluctant to install a security sensitive Firefox addon that is marked "experimental" and hasn't undergone independent code review. Plus, the extension as it stands is Firefox only -- it would be nice to have this same degree of gnome-keyring (or kwallet) integration in Thunderbird.

[Leo-vonklenze (leo-vonklenze)]

Created an attachment (id=432158)
Patch for GnomeKeyring.cpp and Makefile

Hello,

I found a bug in GnomeKeyring.cpp. The following line is wrong
   const char* tempHostname = NS_ConvertUTF16toUTF8(s).get();
because the NS_ConvertUTF16toUTF8 object is destroyed just after this statement. That causes the pointer tempHostname to be invalid. In some cases the memory of this pointer was overidden by subsequent calls before the value was stored in the attribute list.

The changes in install.rdf just enable the extension for thunderbird and newer firefox version which works great on my machine.

Hope this helps,
 Leo

[Yury-sobolev (yury-sobolev)]

(In reply to comment #26)
> The current patch implements nsILoginManagerStorage directly in C++. Another
> approach I thought about would be to wrap the low-level Gnome Keyring API in a
> C++ component and then implement nsILoginManagerStorage in JS. That should make
> things simpler for adding caching (if needed), managing preferences (keyring
> name is hardcoded right now for instance) or others.
> (https://wiki.mozilla.org/JSctypes could be useful here but I don't think it's
> ready yet)

If there is interest, I have a mostly working version written in pyxpcom. It is not quite compatible with the C++ version, but that can be easily changed. I do not think it is especially useful, since it does require the python extensions, but it may be handy for prototyping.

[Michał Gawroński (dinth1906)]

Here is Archlinux package : http://aur.archlinux.org/packages.php?ID=38332

and patch which makes it compile on Arch: http://aur.archlinux.org/packages/firefox-extension-gnome-keyring-git/firefox-extension-gnome-keyring-git/makefile.patch

[Legolas558-users (legolas558-users)]

Wow, 2 years have elapsed, I was using Gentoo then and now I am using Arch. Glad that it is available now, opting out

[Mildred (mildred)]

Is there any information about Firefox support for gnome-keyring?
Currently, the extension http://github.com/nougad/firefox-gnome-keyring isn't supposed to work on Firefox 4 and I have no idea if the porting work is difficult or straightforward.

[Paul-oshannessy (paul-oshannessy)]

(In reply to comment #54)
> Is there any information about Firefox support for gnome-keyring?

Our support hasn't changed. We don't have any support for it natively but overriding the login storage module with an extension should continue to work.

> Currently, the extension http://github.com/nougad/firefox-gnome-keyring isn't
> supposed to work on Firefox 4 and I have no idea if the porting work is
> difficult or straightforward.

The extension probably needs to be updated to handle the changes in XPCOM component registration: https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Component_registration

[Feedback-launchpad (feedback-launchpad)]

typo added the following comment to Launchpad bug report 217300:

Use case:
I like to encrypt all my credentials (website/username/password entries) with a password. But I don't like to enter too many passwords when I use my computer. So i'd like to unlock my keyring with my login password like LightDM and Seahorse do it right know quite well. ("login" keyring) But sadly Firefox doesn't support this feature, so that I have to enter my password a second time.

--
http://launchpad.net/bugs/217300

[Jesse Glick (jesse-glick)]

FWIW Chrome on Ubuntu Oneiric seems to use the login keyring out of the box - and on first start will offer to import your Firefox passwords, copying them to the native keyring.

[Jean-Alexandre Anglès d'Auriac (jagw40k)]

I think this would be much better included in Firefox that as an extension, as both Firefox himself and other extensions can tr

[Jhorak (jhorak)]

So what is current Mozilla point of view to incorporate this enhancement to Firefox directly (without extension)? And if so what is more preferable:
1. store all saved password in keyring
2. store only master password in keyring.

[Dolske (dolske)]

I guess I would say that it's not clear to me that integration with the system keystore provides significant value (cost/benefit), and so I don't see this happening any time soon. I'd also be concerned about it adding complexity for Sync.

The master password is a whole 'nother ball ox wax, still up in the air.

[Bustervill (bustervill)]

Well, the benefit would be a single store for passwords/keys instead of every application having its own.
Firefox is not the center of the universe, you know.
If this feature won't be implemented, then you should close this bug report.
What is the benefit of keeping a feature request open for 7 years if you "don't see this happening any time soon"?

[Romain Chossart (romainchossart)]

This is my own experience, but at the moment Firefox is the only application I use where I need to type a password each time I fire it, due to this lack of keychain integration.

At a time where firefox needs to distinguish itself from his concurrents, it is easy to see the benefits (although I understand the costs might be too high).

[Murz (murznn)]

Expiring same problem too. For KDE environment this issue can be fixed via extension https://addons.mozilla.org/ru/firefox/addon/kde-wallet-password-integratio/ but there are no easy-to-install way for Gnome.

So most of users stores Firefox passwords non-secured like as plain text, this is large security hole!

Using master password is not good solution, because users will must enter it after each restart firefox.

Google Chrome have build-in support for Gnome Keyring and KDE Wallet, so will be good if Firefox can have this support too!

[Mikko Rantalainen (mira)]

For Gnome compatible environments: there's no ready-made extension at addons.mozilla.org but you can fetch the latest version from https://github.com/infinity0/mozilla-gnome-keyring or if you use Ubuntu, you can add PPA from https://launchpad.net/~fat-lobyte9/+archive/ppa-public and install package called "mozilla-gnome-keyring" which will add password integration for both Firefox and Thunderbird.

[tschoie (tschoie)]

(In reply to Mikko Rantalainen from comment #64)
> For Gnome compatible environments: there's no ready-made extension at
> addons.mozilla.org but you can fetch the latest version from
> https://github.com/infinity0/mozilla-gnome-keyring or if you use Ubuntu, you
> can add PPA from https://launchpad.net/~fat-lobyte9/+archive/ppa-public and
> install package called "mozilla-gnome-keyring" which will add password
> integration for both Firefox and Thunderbird.

This is only partly correct as this does not seem to work on Ubuntu >= 12.10. [1] Now I know that Ubuntu is not the only GNOME-based distro and Mozilla doesn't seem to be the one to blame for these particular difficulties, but I as a user of both Ubuntu and Firefox would love to see an implementation of this feature...

[1] https://github.com/infinity0/mozilla-gnome-keyring/issues/26

[Jhorak (jhorak)]

Storing only master password in (Gnome/KDE) keyring could be less complicated in this case and it would still work with Mozilla's Sync, wouldn't it?

[upkpk (upkpk)]

> This is only partly correct as this does not seem to work on Ubuntu >= 12.10.
You should try the official debian package at
http://packages.debian.org/experimental/xul-ext-gnome-keyring

2013/1/14 Jhorak <email address hidden>:
> Storing only master password in (Gnome/KDE) keyring could be less
> complicated in this case and it would still work with Mozilla's Sync,
> wouldn't it?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/41179
>
> Title:
> Integrate with Gnome Keyring
>
> Status in The Mozilla Firefox Browser:
> Confirmed
> Status in “firefox” package in Ubuntu:
> Won't Fix
> Status in “xulrunner-1.9” package in Ubuntu:
> Won't Fix
> Status in “xulrunner-1.9.1” package in Ubuntu:
> Triaged
>
> Bug description:
> For a really good Gnome integration, it would be great to have the
> ability to save passwords in the Gnome keyring.
>
> A similar thing has been proposed for Epiphany: see
> https://launchpad.net/malone/bugs/3467.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/firefox/+bug/41179/+subscriptions

[tschoie (tschoie)]

(In reply to Launchpad from comment #67)
> nodiscc added the following comment to Launchpad bug report 41179:
>
> > This is only partly correct as this does not seem to work on Ubuntu >= 12.10.
> You should try the official debian package at
> http://packages.debian.org/experimental/xul-ext-gnome-keyring
>

Thanks, but this package has an iceweasel/icedove dependency...

[Matěj Cepl (mcepl)]

(In reply to Murz from comment #63)
> So most of users stores Firefox passwords non-secured like as plain text,
> this is large security hole!

No, it doesn't ... Firefox native password store is of course heavily encrypted (although with only optional password, true).

Otherwise, +1 to comment 66 ... unless the solution works with Firefox Sync (and thus with all those smartphones/tables) it couldn't be IMHO a part of the native Firefox.

[Murz (murznn)]

(In reply to Matej Cepl from comment #69)
> (In reply to Murz from comment #63)
> > So most of users stores Firefox passwords non-secured like as plain text,
> > this is large security hole!
>
> No, it doesn't ... Firefox native password store is of course heavily
> encrypted (although with only optional password, true).

How Firefox can heavily encrypt them if user set empty password? As I see, most of users don't want to enter additional password on each open browser, and also many users even don't know about this feature (because Firefox don't suggest to encrypt passwords on install or first start).

So in most of Firefox installs passwords are not encrypted, and any other user can view it (for example via PasswordFox application).

In Google Chrome passwords are encrypted by default in windows via user password (Chrome uses a Windows provided API function which makes the encrypted data only decipherable by the Windows user account used to encrypt the password. So essentially, your master password is your Windows account password), on Gnome - stored in Keyring, on KDE - in KWallet, so user must not enter password on browser start and passwords are stored in encrypted format.

Will be glad to see something solution like in Chrome for password encryption by-default in Firefox.

[Alexander Korsunsky (fat-lobyte9)]

(In reply to Justin Dolske [:Dolske] from comment #60)
> I guess I would say that it's not clear to me that integration with the
> system keystore provides significant value (cost/benefit)
As it has been made clear already, the benefit is
1) that on a usual Desktop, multiple applications need to store passwords and it would be a very intelligent idea to handle all these passwords in one place and
2) that the "Master password" prompt is extremely annoying, especially if one used both Firefox and Thunderbird. Quite frankly, I do not understand why Mozilla devs are so neglecting towards password security! The master password prompt is inconvenient and broken (see [4]) and the only remedy would be to store the passwords in plain text.

(In reply to Launchpad from comment #67)
> > This is only partly correct as this does not seem to work on Ubuntu >= 12.10.
> You should try the official debian package at
> http://packages.debian.org/experimental/xul-ext-gnome-keyring
This is not going to work. The Debian package is linked against libxul, and requires the libxul headers and libraries. These do not exist on Ubuntu >= 12.10. If you try to build it yourself, you will get FTBFS; if you try to use the binary, it simply won't work because of missing libraries.

(In reply to Mikko Rantalainen from comment #64)
> For Gnome compatible environments: there's no ready-made extension at
> addons.mozilla.org but you can fetch the latest version from
> https://github.com/infinity0/mozilla-gnome-keyring or if you use Ubuntu, you
> can add PPA from https://launchpad.net/~fat-lobyte9/+archive/ppa-public and
> install package called "mozilla-gnome-keyring" which will add password
> integration for both Firefox and Thunderbird.
As already mentioned, this will not work on Ubuntu >= 12.10.

Let me explain the situation:
By copying the cool kinds on the block (G. Chrome) and introducing the rapid release cycle for Firefox, Mozilla really made things hard for developers.

Our extension is a binary one (we need to link against libgnomekeyring), so we need to rebuild the extensions for every new Firefox release.
Ubuntu, in an attempt to follow the rapid release cycle, dropped the "xulrunner" library, and build Firefox and Thunderbird seperately. They (understandably) don't want to maintain binary extensions and they (not understandably) removed all headers from the firefox-dev and thunderbird-dev packages [1][2]).
They argue that extension devs should either make their extensions non-binary or that they be integrated into Firefox itself [2].
Now (as I understand correctly) Mozilla is saying they don't actually care?

Let me get this clear. People need this functionality. I can tell you that because otherwise this bug report would not exist for 8(!!!) years and have 70 replies, and most of all because [3] does have a fair amount of users.
Most of the code already exists[3]. Are you (Mozilla devs) saying (or implying by silence) that Mozilla does not give a f*ck about your Users on GNOME?
What happened to "listening to feedback" and "caring about users"? Or do you actually mean "caring about the average Windows users"?

[1] https://lists.ubuntu.com/archives/ubuntu-motu/20...

[Burrito Bazooka (burritobazooka)]

I posted earlier in this thread (probably so long ago that I can't find it :U)

I'd like to reiterate my motion that this is a needed feature. I believe, as an end user, and an experienced computer user, who knows a fair bit about securing end user stuff, I believe that Firefox will be forever incomplete if it does not integrate with the major operating systems' secure password storage systems.

Implement it, please, into Mozilla Firefox itself, so that all users can have a good, easy, and slightly more secure experience in using Mozilla Firefox. As mentioned above, the code is already there. Or, state directly (meaning straight from the developers' mouthes) the major and crippling disadvantage that means that it cannot be implemented. Feel free to use as much technical language as you wish, in order to convince us that your way is correct, so that we can end this 8 year long struggle for one simple feature, one way or another.

Seriously, this is equal to how Yahoo Mail hasn't used HTTPS for ages, until AccessNow made a little noise.

[Burrito Bazooka (burritobazooka)]

Oh, looks like I only subscribed, not posted.

[Gabriele Svelto (gsvelto)]

I think the idea of using the native keyring to store the master password is sound. I'd be glad to try and implement it for gnome-keyring once I've got some spare time on my hands.

[Guillermoadrianmolina (guillermoadrianmolina)]

Hi there, I've made a new extension to store passwords on keyring. It is based on another extension (written by me) that uses kde wallet manager, which was based on the original extension named here. It is being checked right now, but you can download and test it from: http://www.guillermomolina.com.ar/index.php/es/archivos/category/2-firefox-gnome-keyring-extension?download=20:firefox-gnome-keyring-extension-version-0-1

Cheers.

[Burrito Bazooka (burritobazooka)]

I'm very glad that this is making progress, I'm sure others are too :)

[Jhorak (jhorak)]

Created attachment 706354
Store Master Password to Gnome Keyring patch v1

I've made a patch for storing Master password to Gnome Keyring. Not sure who ask for review. I'm trying you neil as long as I see you as peer on Passwords & Permissions module.

[Neil-httl (neil-httl)]

Comment on attachment 706354
Store Master Password to Gnome Keyring patch v1

You need build system and PSM reviews, so I'll just comment on code patterns.

>+ PRUnichar *password = nullptr;
>+ nsAutoString promptString;
>+
>+ // Get prompt message for Gnome Keyring master password
>+ nsCOMPtr<nsINSSComponent> nssComponent(do_GetService(kNSSComponentCID, &rv));
>+ if (NS_FAILED(rv))
>+ return;
>+
>+ const PRUnichar* formatStrings[1] = {
>+ ToNewUnicode(NS_LITERAL_STRING("Gnome Keyring"))
>+ };
NS_NAMED_LITERAL_STRING gnomeKeyring("Gnome Keyring");
const PRUnichar* formatStrings[] = { gnomeKeyring.get() };
Or since this is linux-only, MOZ_LL, NS_LL or u"Gnome Keyring" might work.
This avoids having to free the string manually.

>+ // Return if promp was closed without confirmation or password is wrong
Typo: prompt

>+ if (value)
[I had to look up the .idl to find out what this value meant.]

>+ nsCString utf8password;
>+ utf8password = NS_ConvertUTF16toUTF8(password);
>+ NS_Free(password);
>+ password = nullptr;
>+ if (gnome_keyring_unlock_sync(NULL, utf8password.get()) == GNOME_KEYRING_RESULT_OK)
gnome_keyring_unlock_sync(NULL, NS_ConvertUTF16toUTF8(password).get())

>+ mResult = g_strdup(keyringRecord->secret);
[Does this get freed with g_free?]

[Jhorak (jhorak)]

(In reply to <email address hidden> from comment #78)
> Comment on attachment 706354
> Store Master Password to Gnome Keyring patch v1
>
> You need build system and PSM reviews, so I'll just comment on code patterns.
>
> >+ PRUnichar *password = nullptr;
> >+ nsAutoString promptString;
> >+
> >+ // Get prompt message for Gnome Keyring master password
> >+ nsCOMPtr<nsINSSComponent> nssComponent(do_GetService(kNSSComponentCID, &rv));
> >+ if (NS_FAILED(rv))
> >+ return;
> >+
> >+ const PRUnichar* formatStrings[1] = {
> >+ ToNewUnicode(NS_LITERAL_STRING("Gnome Keyring"))
> >+ };
> NS_NAMED_LITERAL_STRING gnomeKeyring("Gnome Keyring");
> const PRUnichar* formatStrings[] = { gnomeKeyring.get() };
> Or since this is linux-only, MOZ_LL, NS_LL or u"Gnome Keyring" might work.
> This avoids having to free the string manually.

Thanks for feedback.
The u"str" or NS_LL is char16_t*. I'm not sure if I can safely cast it to PRUnichar), can I?

[Mh+mozilla (mh+mozilla)]

(In reply to jhorak from comment #79)
> Thanks for feedback.
> The u"str" or NS_LL is char16_t*. I'm not sure if I can safely cast it to
> PRUnichar), can I?

Note you can't use u"" because that's only supported in c++11 mode, and we still support not building in that mode.

[Jhorak (jhorak)]

Created attachment 707001
Store Master Password to Gnome Keyring patch v2

Fixed patch, asking for review from PSM.
The patch has one drawback though. In Saved Passwords list the master password is not required to show password for each record. However Gnome keyring also allows to show password without typing master password too - user is supposed to lock his screen when leaving his computer alone...

[Jhorak (jhorak)]

Created attachment 709034
Store Master Password to Gnome Keyring patch v3

Changes
 - Prompt user if he wants to store master password to Gnome Keyring.
 - rewritten patch a bit to avoid a lot of nested ifs.
Changing reviewer as long as Kai showed some interest in this patch. Thanks.

[Jhorak (jhorak)]

Created attachment 713377
Store Master Password by using libsecret to Gnome Keyring patch v1

[9-stef (9-stef)]

Comment on attachment 713377
Store Master Password by using libsecret to Gnome Keyring patch v1

Review of attachment 713377:
-----------------------------------------------------------------

Overall looks good. Haven't tested. Just a few comments.

::: configure.in
@@ +4989,5 @@
> +
> + if test "$MOZ_ENABLE_LIBSECRET"
> + then
> + PKG_CHECK_MODULES(MOZ_LIBSECRET, libsecret-1 >= $LIBSECRET_VERSION,[
> + MOZ_LIBSECRET_LIBS=`echo $MOZ_LIBSECRET_LIBS | sed 's/-llinc\>//'`

Are you sure you need this? If so, I'd be interested to know on which platform libsecret has that in its pkg-config file.

::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +751,5 @@
> +on_lookup_finished(GObject *source,
> + GAsyncResult *result,
> + gpointer data)
> +{
> + gchar *pwd = secret_password_lookup_finish(result, nullptr);

Is it worth retrieving the error and logging it if things fail? May make our lives easier in the future if people run into problems and we have to diagnose them remotely.

@@ +803,5 @@
> + nsCString keyDescription;
> + keyDescription.Assign(MOZ_APP_NAME);
> + keyDescription.Append(" - ");
> + keyDescription.Append(profileName);
> + mRunning = true;

May I suggest using (the equivalent of):

MOZ_APP_NAME + " Master Password - " + profileName

So that it's clear in the password manager what this is?

@@ +808,5 @@
> +
> + secret_password_lookup(MOZILLA_SECRET_SCHEMA, nullptr, on_lookup_finished, this,
> + "application", MOZ_APP_NAME,
> + "profile", profileName.get(),
> + NULL);

Are you sure you need to do this as async? I don't understand all aspects of how SyncRunnableBase works, but if this is a separate thread, you could just use secret_password_lookup_sync().

::: security/manager/ssl/src/nsPK11TokenDB.cpp
@@ +388,5 @@
> + };
> + return &the_schema;
> +}
> +
> +#define MOZILLA_SECRET_SCHEMA get_mozilla_secret_schema()

Is there a reason the above function and macro can't be shared between nsNSSCallbacks.cpp and nsPK11TokenDB.cpp?

@@ +400,5 @@
> +on_libsecret_password_stored(GObject *source,
> + GAsyncResult *result,
> + gpointer data)
> +{
> + secret_password_store_finish (result, nullptr);

Is it worth retrieving the error and logging it if things fail? May make our lives easier in the future if people run into problems and we have to diagnose them remotely.

@@ +416,5 @@
> +on_libsecret_password_cleared(GObject *source,
> + GAsyncResult *result,
> + gpointer data)
> +{
> + secret_password_clear_finish(result, nullptr);

Ditto about the error.

[Mh+mozilla (mh+mozilla)]

Comment on attachment 713377
Store Master Password by using libsecret to Gnome Keyring patch v1

Review of attachment 713377:
-----------------------------------------------------------------

::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +800,5 @@
> + rv = profileDir->GetNativeLeafName(profileName);
> + if (rv != NS_OK)
> + return;
> + nsCString keyDescription;
> + keyDescription.Assign(MOZ_APP_NAME);

You don't want to use MOZ_APP_NAME here. Use nsIXULAppInfo data.

[Jhorak (jhorak)]

Created attachment 713868
Store Master Password by using libsecret to Gnome Keyring patch v2

Thanks Stef for feedback. I've fixed mentioned issues.
(In reply to Stef Walter from comment #84)
> @@ +808,5 @@
> > +
> > + secret_password_lookup(MOZILLA_SECRET_SCHEMA, nullptr, on_lookup_finished, this,
> > + "application", MOZ_APP_NAME,
> > + "profile", profileName.get(),
> > + NULL);
>
> Are you sure you need to do this as async? I don't understand all aspects of
> how SyncRunnableBase works, but if this is a separate thread, you could just
> use secret_password_lookup_sync().
>
The secret_password_lookup is called on main thread, so we have to use async function to update gui.

[9-stef (9-stef)]

(In reply to jhorak from comment #86)
> The secret_password_lookup is called on main thread, so we have to use async
> function to update gui.

Makes sense.

[Adrien Dorsaz (adorsaz)]

I've compiled it for Firefox 22 and it seems to work according a Gnome user point of view (but I don't know how to check if my passwords are well encrypted).

Did some Kwallet user try it ? And what will be next step to include this patch in future Firefox release ?

[Dkeeler (dkeeler)]

Adrien - here's some steps you can take:
* Does it apply/compile for mozilla-central? (`hg clone https://hg.mozilla.org/mozilla-central`, `cd mozilla-central`, [apply patch], `./mach build`)
* It still needs (at least) a review from a PSM peer. As far as I know, Kai is unavailable to do PSM reviews. Other peers are listed here: https://wiki.mozilla.org/Modules/All (search for "PSM")
* There are a few build config changes, so it should probably get a review from a build peer (search that same page for "build config" - it's the one related to Gecko)
* You might consider marking old patches obsolete in this bug just to clean it up

[Adrien Dorsaz (adorsaz)]

Ok, I've tried to clone mozilla-central, apply patch and compile, but it wasn't successful.

In fact, I wasn't able to apply the patch and so I've tried to apply manually the changes, but it was a little bit as black magic for me. That's why I've got this compilation error I think : https://pbin.adorsaz.ch/?1b5e8a6be1f8052f#oqW8wBbbIW+kqyleweKWkSlQOEzThNoSfxzaMVofCCY=

I'll attach my patch file, but it doesn't work and it certainly doesn't respect your standards.

[Adrien Dorsaz (adorsaz)]

Created attachment 780879
Modified patch to be applied to mozilla-central, but it won't compile

[Dkeeler (dkeeler)]

Adrien - if you're looking to continue development on this patch, you can see if someone in #developers (see https://wiki.mozilla.org/IRC ) might be able to help you with the compilation issues. At a glance, it looks like you need to add some #includes (specifically, #include "nsDirectoryServiceUtils.h" and maybe #include "nsIFile.h" in this case).

[Gabriele Svelto (gsvelto)]

Created attachment 785385
Refreshed patch

This is a refreshed version of attachment 713868; the changes were fairly minimal as noted in comment 91 and comment 92. Besides adjusting a few rejections it was just a matter of importing nsIFile.h to get it working.

I've done some light testing on my box, adding and removing the master password as well as externally deleting it from the key-ring and it seems to work fine.

Adrien, if you want to pick this up you can start working using this patch; otherwise I'd be keen on finishing this myself as this is a feature I've been sorely missing.

[2-brian (2-brian)]

(In reply to David Keeler (:keeler) from comment #89)
> * It still needs (at least) a review from a PSM peer. As far as I know, Kai
> is unavailable to do PSM reviews. Other peers are listed here:
> https://wiki.mozilla.org/Modules/All (search for "PSM")

I am the PSM module owner but I am not even a peer in the toolkit or Firefox modules where the password manager lives. I am very interested in removing all the master password prompts on all platforms.

I know very little about Linux compared to most of the people CC'd on this bug; please be patient with me if I say something stupid.

1) I see in the patch that this is a build option that is off by default. I would prefer it to be ON by default for all Linux desktop builds, and if libsecret isn't available at runtime, then we just don't use it and we disable the Firefox UI related to the Gnome Keyring. Is there anything inherently wrong with doing it this way?

2) The patch contains a prompt that asks "Do you want to save master password to system password manager?" But, this seems like the wrong question. I think, instead, the "Change Password" dialog box should look something like this:

    (*) Protect my data with my system password (recommended)
    ( ) Use a master password:
        New Password: [ ]
        Confirm Password: [ ]
    ( ) Don't protect my data

If we did it this way, then we wouldn't need that separate prompt. Also, this UI would work for all operating systems, AFAICT. (Note: I am not a UX person and in theory a UX person should design the UI for this. However, this may get blocked for a long time if we wait for a UX person to design it, so I suggest you build a prototype UI and have the UX people review it. If it works well on Linux then we could port the same UI to other platforms.)

3) The Gnome keyring should never store/protect a password that the user entered. Instead, it should store a randomly-generated key (e.g. 32 bytes of randomness from nsIRandomGenerator, or similar). NSS's protection of the master password is very weak, and also users will almost always choose relatively weak passwords, so using a random key as the NSS password is important.

4) Some people at Mozilla are working on this "Sign into the browser" / "Profile in the Cloud" thing, of which Sync is a part. See https://wiki.mozilla.org/Identity/AttachedServices. I think it is important to make sure that the people working on this feature discuss it with the the Identity people to make sure that this work and that work is compatible/complementary.

[2-brian (2-brian)]

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> 2) The patch contains a prompt that asks "Do you want to save master
> password to system password manager?" But, this seems like the wrong
> question. I think, instead, the "Change Password" dialog box should look
> something like this:
>
> (*) Protect my data with my system password (recommended)
> ( ) Use a master password:
> New Password: [ ]
> Confirm Password: [ ]
> ( ) Don't protect my data
>
> If we did it this way, then we wouldn't need that separate prompt.

Now, let me argue against myself.

Shouldn't the users that care about protecting their passwords be using full-disk encryption with a system password already? Why don't we just remove the master password mechanism on Linux completely, and rely on users use of operating-system-level protection of their whole profile? That is, wouldn't the best UI be this?:

      Mozilla recommends that you use a system password
      and full-disk encryption to protect your data; if
      you do that, then a master password is not very
      helpful. We still support using a master password
      for now, but we highly recommend against using
      one, and we may remove this misfeature in a
      future version.

      [ ] Use a master password:
          New Password: [ ]
          Confirm Password: [ ]

[Gabriele Svelto (gsvelto)]

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #95)
> Shouldn't the users that care about protecting their passwords be using
> full-disk encryption with a system password already? Why don't we just
> remove the master password mechanism on Linux completely, and rely on users
> use of operating-system-level protection of their whole profile?

Full-disk encryption won't be available to whoever is storing its data on a computer he/she doesn't control. For example you might have to keep your profile on a shared drive when working in an office (alas that's a situation I have been in multiple times) and for those use cases providing a way to encrypt your saved passwords is very important.

[Gabriele Svelto (gsvelto)]

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> 1) I see in the patch that this is a build option that is off by default. I
> would prefer it to be ON by default for all Linux desktop builds, and if
> libsecret isn't available at runtime, then we just don't use it and we
> disable the Firefox UI related to the Gnome Keyring. Is there anything
> inherently wrong with doing it this way?

It shouldn't be a problem if we can dynamically load the library at runtime.

> 3) The Gnome keyring should never store/protect a password that the user
> entered. Instead, it should store a randomly-generated key (e.g. 32 bytes of
> randomness from nsIRandomGenerator, or similar). NSS's protection of the
> master password is very weak, and also users will almost always choose
> relatively weak passwords, so using a random key as the NSS password is
> important.

This has a drawback however: if for some reason you lose your keyring then you loose all your saved passwords. It also means that you can't move your profile across machines unless you also move the keyring (or write down the random-generated password). If the master password by itself is week wouldn't it be better to generate a random salt and store it in plain-text in the profile and then use the master password + salt for the encryption? That would improve the effectiveness of the resulting encryption while keeping a password that cannot be remembered by the user. Would there be any downsides to doing it this way?

[Martin Schröder (martinschroeder)]

What are the downsides of completely relying on libsecret for storing passwords instead of a proprietary solution? Then a user had all his passwords in his keyring and wouldn't have to care about other locations where passwords are stored.

[Jhorak (jhorak)]

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> 4) Some people at Mozilla are working on this "Sign into the browser" /
> "Profile in the Cloud" thing, of which Sync is a part. See
> https://wiki.mozilla.org/Identity/AttachedServices. I think it is important
> to make sure that the people working on this feature discuss it with the the
> Identity people to make sure that this work and that work is
> compatible/complementary.
AFAIK this has nothing to do with master password. Master password is not send to Sync service and user is not required to set master password on other Firefox instances, but it's good to keep Sync in mind.

(In reply to MartinSchroeder from comment #98)
> What are the downsides of completely relying on libsecret for storing
> passwords instead of a proprietary solution? Then a user had all his
> passwords in his keyring and wouldn't have to care about other locations
> where passwords are stored.
This is also an option but it requires more libsecret binding:
Getting list of passwords for Saved Passwords dialog and allow to remove individual records if we want to keep Saved Passwords and Sync working.

Personally I would stay with currently easiest solution which is storing user defined master password to libsecret's keyring. It's up to user to set strong password for Firefox and Keyring. They have probably weak password now because they have to retype it frequently. If they didn't have to they would eventually set stronger password. It's also smaller change to introduce new bugs since we're doing lesser change.

[Jesse Glick (jesse-glick)]

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> The Gnome keyring should never store/protect a password that the user
> entered. Instead, it should store a randomly-generated key

Agreed that it feels unnatural to have to define a master password when you are using the native keyring. But bear in mind that the whole approach of continuing to use proprietary password storage, and keeping only a single decryption key in the native keyring, is unnatural to users and has the sole merit (I presume) of requiring fewer code changes. Proper integration means storing all passwords as regular entries in the native (login) keyring, where they can be inspected and even edited using standard tools like seahorse. This is what Chrome seems to do, and what you would expect any polite application to do.

[2-brian (2-brian)]

(In reply to Jesse Glick from comment #100)
> Agreed that it feels unnatural to have to define a master password when you
> are using the native keyring. But bear in mind that the whole approach of
> continuing to use proprietary password storage, and keeping only a single
> decryption key in the native keyring, is unnatural to users and has the sole
> merit (I presume) of requiring fewer code changes. Proper integration means
> storing all passwords as regular entries in the native (login) keyring,
> where they can be inspected and even edited using standard tools like
> seahorse. This is what Chrome seems to do, and what you would expect any
> polite application to do.

Let's please tone down the rhetoric regarding "proprietary" a little bit. The Gnome keyring is no less proprietary than any part of Firefox is.

I am not opposed to Firefox doing what you suggest if it isn't problematic to do so. But, please explain how a user would switch from Linux to Windows and bring their passwords with them; then please explain how a user would switch from Windows to Linux and get their passwords in the Gnome keystore. Right now a Firefox user can just copy their profile directory over to the new platform and they're done. With the "random master password" mechanism, they would have to first change from the random password to a user-entered password before copying the profile files over. With the "all passwords stored in the OS keyring directly" approach...I am not sure; help me understand what would happen.

Also, syncing of passwords across devices is a must-have requirement. So, any solution for this bug must support Firefox Sync, and must not complicate the implementation of the upcoming improvements to Firefox Sync.

[Jesse Glick (jesse-glick)]

> explain how a user would switch from Linux to Windows and bring their passwords with them

Same way you would for secrets used by any other application: enter them again. This is an OS/desktop issue, not the responsibility of an individual application. Of course if you have decided to use cloud password storage like Sync then that would be your means of sharing secrets across machines.

By the way Windows seems to have no general service comparable to GNOME Keyring or KDE Wallet or OS X Keychain. It does have CryptProtectData, meaning that on Windows it is appropriate for Firefox to store its own passwords so long as it uses this API to prevent them from being kept on disk in cleartext.

[Martin Schröder (martinschroeder)]

Sorry for introducing the "proprietary" term. I didn't assign any judgement to it.

Wouldn't it be optimal, if Sync would be able to store and load into and from a file? Then the data could be brought everywhere without storing it online. This way the differences between systems wouldn't matter.

[Jhorak (jhorak)]

(In reply to Jesse Glick from comment #102)
> > explain how a user would switch from Linux to Windows and bring their passwords with them
>
> Same way you would for secrets used by any other application: enter them
> again. This is an OS/desktop issue, not the responsibility of an individual
> application. Of course if you have decided to use cloud password storage
> like Sync then that would be your means of sharing secrets across machines.

Why not make it still possible? I see no benefit in retyping password when copying profiles. IMO profile should contain all data user wants it to store (ie. also list of passwords). Anyway do the libsecret supports KDE right now? If it doesn't we could probably cut password store support by this change for KDE users or implement another kwalletd backend.

I think storing master password in system keyring manager is making things more loosely coupling. In case system keyring manager doesn't provide master password then we fallback to user input of master password. In case we saved all passwords to keyring and for some reason keyring won't be available users wouldn't have a change to have they passwords pre-filled.

[Jesse Glick (jesse-glick)]

(In reply to jhorak from comment #104)
> do the libsecret supports KDE right now?

https://wiki.gnome.org/Libsecret says it does.

[Martin Schröder (martinschroeder)]

(In reply to Jesse Glick from comment #105)
> (In reply to jhorak from comment #104)
> > do the libsecret supports KDE right now?
>
> https://wiki.gnome.org/Libsecret says it does.

The site says that libsecret supports ksecretservice. And ksecretservice is not working very well and is not included by default (AFAIK).

But what is the problem with using libsecret under Gnome and Firefox' own storage under KDE? Then it's like before under KDE until they have a freedesktop.org compatible key storage.

[9-stef (9-stef)]

Hey guys, just wanted to give a heads up here...

I gave a talk at GUADEC which presented an alternate password storage model, where the secret service provides a master key to apps (like firefox) via standard interfaces like the linux kernel keyring. Apps can use this key to encrypt their own password storage database.

The above works well in the case of sandboxing. I think it also fits really well within the firefox model. You don't have to worry about things like async access for each password to another daemon.

I feel bad posting this here without more details, but over the next few days I'm going to clean up my slides, and do some blog posts about this.

You can see a bit of history here:

http://lists.freedesktop.org/archives/authentication/2013-May/000267.html

[Martin Schröder (martinschroeder)]

I think we have to differenciate between two levels:
- The ability to *securely* store passwords (with a master password or a key provided by the system's key manager)
- The ability to securely *store passwords in the system's key manager*, where all my passwords live.

I favor the second option. I'm not concerned about moving passwords between different systems (that should happen rarely). And if I happen to use multiple devices: That's what Sync is for.
I am concerned about storing my passwords in a way that I trust: my system's key ring (storing keys is it's only purpose and I think it should be good at it).

Of course the thoughts in the link posted above[1] are also good ones.

[1]
http://lists.freedesktop.org/archives/authentication/2013-May/000267.html

[Jhorak (jhorak)]

Okay, it seems that we're moving in circles. Who's going to decide which approach to choice? I can implement storing password to system keyrings but I won't do this without clear statement from Mozilla what they would like more. I still prefer storing only master password because of loose coupling.

[Gabriele Svelto (gsvelto)]

Created attachment 790711
Refreshed patch

(In reply to jhorak from comment #109)
> Okay, it seems that we're moving in circles. Who's going to decide which
> approach to choice? I can implement storing password to system keyrings but
> I won't do this without clear statement from Mozilla what they would like
> more. I still prefer storing only master password because of loose coupling.

I am also in favor of storing the master password in the keyring as it seems the less intrusive approach and the most likely to land soon. It might not be a perfect solution but it improves the usability of the master password a lot. Besides once the harness is in place it will be easier to change the behavior (to store a random password, add a salt or whatever else). The only thing that we might want to change compared with the existing patch (of which I'm reattaching a refreshed version again) is probably in the UI part where we probably want the option to be shown in the same dialog as the master password instead of on a separate pop-up.

I've looked at the password manager log and it seems to me that Justin Dolske comes up often both as a contributor and a reviewer so I'm needinfo'ing him here as he's both a Firefox and Toolkit peer in the hope he's the right person to ask. Justin could you have a look at the approach we're taking here or point us to someone who could help out with this?

[Pb-dsp-bugzilla (pb-dsp-bugzilla)]

Regarding the UI: If you go with the master password option (for now if not permanently), I would suggest adding two features to the Master Password dialogue: a checkbox to store the password in the user’s key{ring|chain}, and a button to generate a random password. The button would lead to an additional UI, which would include a checkbox to toggle showing the password. The “show password” box would default to the logical inverse of state of the “store in my key*” box (since it makes no sense to generate a random password and then neither store it nor show it).

Does this sound reasonable?

[Gabriele Svelto (gsvelto)]

(In reply to David Webb from comment #111)
> Does this sound reasonable?

Yes, it sounds like a good idea but also material for a follow-up. Let's open a separate bug for that so that we don't make the patch here too large or we'll never be done with it :)

[Dolske (dolske)]

(In reply to Gabriele Svelto [:gsvelto] from comment #110)

> I've looked at the password manager log and it seems to me that Justin
> Dolske comes up often both as a contributor and a reviewer so I'm
> needinfo'ing him here as he's both a Firefox and Toolkit peer in the hope
> he's the right person to ask. Justin could you have a look at the approach
> we're taking here or point us to someone who could help out with this?

It's a NSS/PSM patch, so that would be Brian Smith. But I'd have some of the same concerns he's noted in previous comments.

In general, I'd say that (1) the existing master password stuff is a giant mess that doesn't address modern threat models (2) we shouldn't pile more onto that shaky foundation and (3) neither the master password nor extensible nsILoginManagerStorage interface are very successful features.

So, I don't think we should invest time into supporting this, and it would be better implemented as an add-on for those who want it. Sorry. :/

[Alexander Korsunsky (fat-lobyte9)]

(In reply to Justin Dolske [:Dolske] from comment #113)
> So, I don't think we should invest time into supporting this, and it would
> be better implemented as an add-on for those who want it. Sorry. :/

This HAS been implemented as an addon: https://github.com/infinity0/mozilla-gnome-keyring

The problem is that it has to be a binary add-on and is therefor next to impossible to maintain with Firefox' rapid release cycle. Some Linux distributions don't even ship Firefox development headers anymore, and comment it with "this should be integrated into Firefox, please contact upstream".

This is a pledge from a user: PLEASE integrate this patch. This is functionality that is wanted and needed (since the Master-password stuff is indeed a giant mess) by a lot of people and you even have a patch provided and people willing to maintain it.

[Mh+mozilla (mh+mozilla)]

(In reply to Alexander Korsunsky from comment #114)
> This HAS been implemented as an addon:
> https://github.com/infinity0/mozilla-gnome-keyring
>
> The problem is that it has to be a binary add-on (...)

This isn't true. jsctypes can be used to call whatever APIs the binary addon uses.

[Romain Chossart (romainchossart)]

> So, I don't think we should invest time into supporting this, and it would
> be better implemented as an add-on for those who want it. Sorry. :/

I would have thought you should invest time on what matters to users. This feature has a fair amount of votes and the absence of this feature is one of the most obvious and annoying thing on Firefox compared to Chrome: I am sure many users have had to type their master password thousands of times so far because of this. Also this is my own opinion, but I find this popup _soooo_ annoying.

Also, were there an up-to-date add-on, I would not trust it as much as if it was built-in. Such security features should be built-in IMO.

[Dolske (dolske)]

Investing time is always a tradeoff. I have a long list of projects to dramatically improve Firefox for users, and unfortunately the feature this bug about ranks poorly against that list. The number of users using a master password and linux is relatively tiny, and there are number hurdles to even making this a feature suitable to ship (see Brain's previous posts for a few). That's why an add-on is the right route to take.

[Burrito Bazooka (burritobazooka)]

I don't know much about the internal workings of the Firefox Project, but I'm willing to bet that those people using Linux AND using a master password AND Firefox are of a demographic that would be resistant to sending anonymous usage data.

[Joachim R. (jro)]

(In reply to Justin Dolske [:Dolske] from comment #117)
> Investing time is always a tradeoff. I have a long list of projects to
> dramatically improve Firefox for users, and unfortunately the feature this
> bug about ranks poorly against that list. The number of users using a master
> password and linux is relatively tiny, and there are number hurdles to even
> making this a feature suitable to ship (see Brain's previous posts for a
> few). That's why an add-on is the right route to take.

You made a wrong assumption. This feature is not only for master password users. I don't use it be cause it is stupid. I have a session password on my OS, and I expect it to protect everything else. I don't want to have thousands of passwords to manually keep in a text file or a third party keayring software.
The master password and the lack of native keyring support are 2 reasons leading me to switch to Chrome on all of my non-home or mobile devices.
On my Ubuntu home desktop, I tried to use an encrypted home dir, but FF is using I/O too much, so it was too slow and laggy.
The most secure is my MacBook Pro whose disk is fully encrypted and whose web browser (Chrome) is using keyring.

Using the keyring is exactly what I expect from ANY application, thus Firefox, that need a secret key to protect data without pissing me off with one more password. This is a seamless solution for every non-technical, IT-ignorant user. Those user are not using master password, so keyring would be a great solution to add protection without increasing complexity.

I know that there is some technical challenges to add keyring stuff to FF, but whining is not a solution, and believing there is more important UX stuff to do before is an error. This is a security concern, perhaps the #1 security concern in FF. Or if you prefer being troll-flammed by newpapers (http://www.theguardian.com/technology/2013/aug/07/google-chrome-password-security-flaw)...

I have not the C/C++ skills and the FF code base knowledge to help you so I can only encourage you and critisize reluctant attitudes that are legions in Mozilla organization (and sometime at a high hierarchy level... I had a bad experience with Tristant Nitot leading a big French bank switching from IE6 to IE8 instead of FF).

Please get into the future with implementing the keyring. Future is not only HTML5/CSS3 and Co.

[Evan Derickson (derickson-e)]

(In reply to Justin Dolske [:Dolske] from comment #117)
> Investing time is always a tradeoff. I have a long list of projects to
> dramatically improve Firefox for users, and unfortunately the feature this
> bug about ranks poorly against that list. The number of users using a master
> password and linux is relatively tiny, and there are number hurdles to even
> making this a feature suitable to ship (see Brain's previous posts for a
> few). That's why an add-on is the right route to take.

Applications should always make security easy. If a user has already taken the step of selecting an OS with a keyring function, FF should honor her decision and use that keyring, without extra steps required.

FF has been a keystone of exposing users to the quality that the open-source ecosystem can create. It's THE default browser of the most popular GNU operating systems. I'm not a developer (yet), and I can't make these changes myself (yet), I can't force anyone else to, and I greatly appreciate the time that has gone into making FF what it is. But if we want FF to continue to be the foundation of the FOSS ecosystem that it has become, then it should make security easy. As is, users have these choices:

* install an addon ("Why doesn't this software come with essential features already installed?")
* use a master password ("Another password? I just made a system password!")
* do nothing and use the password store w/out master password (user thinks she is secure; she isn't)
* copy/paste from the system keyring or another software (like an addon, only less convenient)
* disable password storage altogether and use sticky notes on the monitor

The default browser on Mac OS already provides a secure, convenient password experience. The default browser in Ubuntu, on the other hand, doesn't reach the bar set by many FOSS projects in leveraging *existing* tools, waiting to be used, instead re-inventing the wheel and forcing redundant user actions.

GNU operating systems are trying to reach out to less-technical users. Firefox should help these efforts by at least meeting the standard of security set by the competition, as a standard feature. Not as an addon.

[upkpk (upkpk)]

Is there any update/ongoing work on this?

There are several attacks out in the wild that allow extracting passwords from the firefox store. As it has been said before, non-technical users will not use the master password (I don't use it either because it bugs me with yet another password prompt). Implementing this would be a major step forward in improving users' security.

[Eric Toombs (ewtoombs)]

(In reply to Mike Hommey [:glandium] from comment #115)
> (In reply to Alexander Korsunsky from comment #114)
> > This HAS been implemented as an addon:
> > https://github.com/infinity0/mozilla-gnome-keyring
> >
> > The problem is that it has to be a binary add-on (...)
>
> This isn't true. jsctypes can be used to call whatever APIs the binary addon
> uses.

And just which javascript api has access to my gnome keyring? God willing, none! If there is a hope in hell for this thing to be secure, it can't be done in javascript. So, yeah. It has to be a binary plugin.

[Gavin Sharp (gavin-sharp)]

(In reply to Eric Toombs from comment #122)

You should give https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes a read - JS used in Firefox add-ons is privileged and can use JS-ctypes to interact with system libraries.

[Markhkamp (markhkamp)]

In response to claims of Chrome's superior password management, I just lived through a use case where keeping the browser's passwords decoupled from the system is much easier to work with.

Short version: Changing Linux distros broke Chromium's access to my saved passwords. Please don't introduce such a fragile dependency in Firefox. I don't want to be locked in to my current OS just to keep using the same cross-platform browser.

Long version:

I had been using Chromium on Chakra Linux for a few years. Chakra is a "half-rolling" distro built around KDE, so it gets the latest KDE stuff faster than most other distros. Then I lived somewhere with metered Internet access for a couple months, so I switched to Firefox, using the lazy tab loading on start-up to reduce bandwidth use.

(off topic: It was really annoying manually importing passwords to Firefox since it doesn't have the feature. I miss Chrome's process-per-tab model that keeps the rest of the browser fast when one tab is busy. At least NoScript mostly keeps tabs from getting too busy in the first place. Also Firefox's Tree Style Tab add-on makes it much easier to keep a zillion tabs organized.)

Now that I'm living somewhere with unmetered Internet again, I've decided it's about time to do some distro-hopping and see how things have changed. Switching between various distros and desktop environments/window managers, Firefox has consistently given me access to my passwords via the master password, even when Firefox's version got shuffled back and forth.

Eventually, I ended up settling on OpenSUSE 13.1 using KDE, but apparently with a slightly older and incompatible version of kwallet. I just opened Chromium for the first time since July. Since all my log-ins have expired, it wants to access saved passwords. However, despite using the same browser and desktop environment I had been in July, with both within a year of the other, Chromium cannot access my saved passwords. I'm stuck with kwallet giving me an "Error code -4: Unsupported file format revision" message. So much for Chromium. Maybe it'll work again on OpenSUSE 13.2 in a couple months?

I guess I'll use Chromium for all the complicated "web 2.0" stuff that Firefox's single process chokes on. Firefox still seems best for not randomly losing abilities and for being widely extensible.

[George Politis (gpolitis)]

(In reply to Mike Hommey [:glandium] (out from Sep 6 to Sep 22) from comment #115)
> (In reply to Alexander Korsunsky from comment #114)
> > This HAS been implemented as an addon:
> > https://github.com/infinity0/mozilla-gnome-keyring
> >
> > The problem is that it has to be a binary add-on (...)
>
> This isn't true. jsctypes can be used to call whatever APIs the binary addon
> uses.

Right, and this has been implemented as a pure JavaScript addon:
https://github.com/swick/moz-gnome-keyring-integration

[Evan Derickson (derickson-e)]

Note that https://bugzilla.mozilla.org/show_bug.cgi?id=106400 is the counterpart for Mac OS X. It has a little under twice the votes and twice the age of this bug. Any work on one of these bugs would likely benefit the other. Maybe there should be an OS-neutral metabug for the two?

[simon (p-info-1)]

Hey who will bake a ten year anniversary cake for this bug report? I'm no longer gonna wait and decided to move on. typing my master password ten times a day pisses me of enough to search for a solution and seeing no progress made on a fundamental shortcoming gives me enough motivation to search for another solution.

bye.

[Mattn+bmo (mattn+bmo)]

Here are extensions that implement this functionality so you don't need to wait for it to be built-in:
* https://addons.mozilla.org/en-US/firefox/addon/gnome-keyring-integration-1/
* https://addons.mozilla.org/en-US/firefox/addon/gnome-keyring-integration/
* https://addons.mozilla.org/en-US/firefox/addon/kde-wallet-password-integratio/

Please keep comments constructive and see the Bugzilla Etiquette guide: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

[Murz (murznn)]

I already try to use those extensions, especially KDE Wallet password integration but it works bad: it broke password sync feature and produce browser crashes, and author don't know how to fix this. So native support for password managers will be much better.
At now I remove master password and forced to store Firefox passwords unsecured :(

[Jhorak (jhorak)]

Can someone summarize conclusion from Mozilla's site? I can work on it but not until there's a clear what is required.

[:gsvelto] are you willing to participate on the reviews?

[Gabriele Svelto (gsvelto)]

(In reply to Jan Horak from comment #130)
> [:gsvelto] are you willing to participate on the reviews?

I'd love to help but I'm not a peer of this part of our codebase so I can't review patches for it. Reading Brian Smith's and Justin Dolske's comments I think that we'd like to address bug 973759 first so that the master password does actually provide reasonable protection.

Personally I'm a user of this particular feature and I'd like to see something like comment 94 being implemented but I'm not the one calling the shots here.

[antistress (antistress)]

It seems that Frederic Crozat is working on it ?
see https://hackweek.suse.com/12/projects/746 & https://github.com/swick/moz-gnome-keyring-integration/issues/2#issuecomment-107093071

[Sebastian Wick (wick-sebastian)]

The move to WebExtensions (with the currently exposed and planned API) would make the all the addons providing gnome/KDE/libsecret keyring support impossible.

Are there plans to provide those APIs?

If not could we take another look at implementing the support directly into firefox?

[Mattn+bmo (mattn+bmo)]

Comment on attachment 713868
Store Master Password by using libsecret to Gnome Keyring patch v2

Clearing ancient review flag on a patch I assume doesn't apply anymore.

[C4609174 (c4609174)]

Please integrate this feature into Firefox, so that the old legacy GNOME add-ons for this task are obsolete. It would be nice to fix this before FF 57, when only WebExtensions are supported.

[Tiago de Paula Peixoto (count0)]

12 years on, we're back to square zero with firefox 57, as the available extensions became incompatible. So depressing.

[Joachim R. (jro)]

The madest thing for me is that now other browsers integrate with platform keyring. Why not Firefox ?
 - Since other browsers have it, political arguments are weak
 - Since Quantum overhaul, technical one are weak too. Mozilla had an opportunity to deal with is issue that is a *major* usability and security issue.

Let's say FF displays the profile in a corner like Google Chrome. Let's say this could be associated with a FF Sync account. On profile switch, it could ask for password or not, depending on a user profile locking pref.
We already know the OS user is able to unlock all FF identifier stores, because this is how keyring work. But with a live (vs on startup) profile management, FF could offer the opportunity to manage switching.

Just my 2 cents, but 12 years on, it is time to look at what other successful browser are doing...

[gunwald (gunwald)]

I totally agree. Just imagine that Firefox still saves all your passwords unencrypted to your disc in it's default configuration. Who else does that in our times?
The refusal to deal with this major security flaw is absolutely unacceptable! And I think it's a sign of poor leadership. They concentrate on total crap like pocket, just an other cloud shit, that no one will ever need, instead of concentrating on privacy an security.

[Sledru (sledru)]

I am restricting this bug to users with the editbugs permissions. We understand that some people are unhappy about this missing feature but the "metoo" comments are not helping.

[Mattn+bmo (mattn+bmo)]

At this point I wouldn't take a patch to implement this as it would be a significant cost with per-platform support. Extension APIs (which I know aren't yet available) would be the solution for implementing this if there is enough demand.

[Martin (martin22)]

*** This bug has been marked as a duplicate of bug 1586072 ***