I would like to port my add-on StartupMaster to the new WebExtension framework. At the moment there is no API for master password management, so I'm proposing one in comment 1.
The main aspects I considered when designing the API were: - It should provide the necessary functions for currently available add-ons, most notably StartupMaster and Master Password+, but also some others , exposing parts of nsIPK11Token that are actually used. This deliberately excludes functions to block or intercept master password popups, which are used by  and , but would better suit the login storage API proposed in bug 1344788. It also obviously excludes XUL overlays such as the ones used in  and . - It should not be a direct wrapper for nsIPK11Token/nsIPK11TokenDB. Bug 1271851 proposes decoupling the master password UI from the PSM and rewriting it from scratch, and I would like this API to remain forward-compatible. Therefore the functions should pertain to the master password and not security devices as in nsIPK11Token. This change also explicitly restricts operation to the internal key token ("software security device"). - Any of the potentially destructive operations like setting up, changing, removing or resetting the master password should pop up a modal chrome dialog for the corresponding operation instead. This makes the API permission safer to grant and covers usage by existing add-ons. - Keep it simple. I would like to land it before Firefox 57 is frozen, otherwise it will hit hard on everyone affected by bug 177175 who rely on  or  as a workaround. - There is one exception where I went against the "keep it simple" rule, by adding a direct option to ask for the master password on startup. This requires blocking on the main thread before other threads are forked off, and WebExtensions are (or soon will be) loaded in a separate thread, which is too late. Based on the above points, I would like to create a WebExtension API with the following functions: - query if a master password is set - query if the password store is unlocked (i.e. the master password was entered) - ask the user to unlock the password store by entering the master password * option: ask even if the password store is already unlocked - lock the password store (require master password reentry on next use) - show the dialog for setting up a master password - show the dialog for changing the master password (ATM it's the same one, but let's not hard-code that) - show the dialog for removing the master password - show the dialog for resetting the master password - set a switch to ask the master password on app startup * option: quit if the dialog is canceled Later, an event handler could be added that fires whenever the password store changes state, but it's not a priority as none of the add-ons use it at the moment. I'm happy to write the patches, but I would first like some review or triage of the proposed interface.  https://addons.mozilla.org/en-US/firefox/addon/startupmaster/  https://addons.mozilla.org/en-US/firefox/addon/master-password/  https://addons.mozilla.org/en-US/firefox/addon/master-password-timeout/  https://addons.mozilla.org/en-US/firefox/addon/master-password-reset/  https://addons.mozilla.org/en-US/firefox/addon/master-password-timeout-upd/  https://addons.mozilla.org/en-US/firefox/addon/masterpassword-firefox/  https://addons.mozilla.org/en-US/firefox/addon/show-password-on-input/
cc'ing in security for some help on this one.
Hi Tamas and Paul, this has been added to the agenda for the June 20 WebExtenion APIs triage meeting. Would you be able to join us? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting Agenda: https://docs.google.com/document/d/1s2j85VfYKTDftppFU-K7pgRs6sEuMTHVXqf3RL5iYvs/edit#
Would it make sense to get some input from security about this first?
My bad, I should have checked in before adding this to the agenda. Paul, would you have time to take a look at this before Tuesday at 10am Pacific? If not, no worries -- we will reschedule this for an upcoming meeting after the All Hands.
I'm afraid I'll be right in the middle of a flight. Is there anything I can contribute in advance?
Kev is also suggesting including Sandy Sage from the lockbox team in this discussion in case there's a touchpoint with this.
I just discussed this with Devin Reams and he will follow up accordingly. I don't think there is currently a touchpoint with us yet but we're still actively watching this thread.
[drum fill] Last Nightly update finally killed off the last working code: MasterPassword+. I have no further working master password timeout addons (from now on the master password doesn't inactivate in 5 minutes, sending otherwise good security down the dumps).
Just to clarify, andym, does P5 mean I can start working on a patch?
It's still [design-decision-needed] meaning we aren't sure if it will be accepted. You can start on a patch, but without a comment from a peer you are taking on the risk of working on something that might be rejected. Of course, a proof of concept might persuade people that its a good idea. cc'ing dreams from comment 9
As the engineering manager of a new team at Mozilla focused on these kinds of things: the initial proposal is a good starting point to discuss. And while I hate to be discouraging I'll echo the risk andym highlighted: the scrutiny around design details (especially from a security perspective) for this kind of interface will be high. Worth adding: many of us recognize Master Password's current implementation is not ideal (documented in many other bugs not worth going into here). Thus, all of Master Password is subject to change as our team (among others) plan to explore this. We'd appreciate input like this once that planning gets started. This is worth considering: valuable time spent now, on an API folks would come to rely upon, could be wasted (or lead to breaking changes and re-work) based on decisions we start to make on a parallel path. That all said, we're very interested in helping make something like this happen and want to work on it together with you all in a thoughtful, secure way. We all sympathize with the need to have _something_ once 57 lands. But, for what its worth, my team would not be able to help contribute here for at least a few months.
To be honest, I think Startup Master a "crude" workaround for a problem which should not exist in the first place. If Firefox would not spam 10 master PW popups in rapid succession after opening (esp. with Sync enabled), there would be no need for this plugin. This is incredibly annoying behaviour and I really can't believe this has not been fixed yet. Sadly enough, all the other bugs seem to be stale or are being ignored, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=177175 If you (@Mozilla) really decide to kill this functionality with 57, PLEASE make sure those bugs are either fixed or re-enable the functionality needed for Startup Master in WebExt. Otherwise you'll probably loose a lot of the 21k users this addon has. Thanks @htamas for maintaining this plugin though, you improved the UX for everyone using a master password a lot over the years. Sorry for some off-topic.
(In reply to Carsten from comment #14) > To be honest, I think Startup Master a "crude" workaround for a problem > which should not exist in the first place. I partly agree, because this was the main issue why I installed StartupMaster some years ago. But then I found the option to quit on cancel being very useful! Of course, it's no real security protection, because one could still run the program deactivating all addons - but it's at least a good way to keep children or low-skilled guys from opening my browser without permission... (In reply to Tamas Hubai [:htamas] from comment #1) > - There is one exception where I went against the "keep it simple" rule, by > adding a direct option to ask for the master password on startup. This > requires blocking on the main thread before other threads are forked off, > and WebExtensions are (or soon will be) loaded in a separate thread, which > is too late. I had some quick idea how to avoid blocking (at least) all other threads: Inside the "ask the user to unlock the password store by entering the master password" there could be a check whether any other instance of this dialog is already shown and to focus to that instead of opening a new one. BTW this would solve bug #177175 implicitly. > - set a switch to ask the master password on app startup > * option: quit if the dialog is canceled Maybe another solution would be to integrate this option in the default preferences, where you could set the master password. Ending up in integrating Startup Master in the default code base. But as this does not remove the need for a Master password API, this comment is rather related to bug #177175.
Whiteboard: [design-decision-needed][triaged] → [design-decision-needed][triaged] [needs-follow-up]
Our current solution for restricting access to Firefox by asking the master password on startup (and to all other add-on compatibility issues) is to use Firefox ESR release. According the current release schedule , Firefox ESR 60.0 is about to be released in 3 months. Are there any plans to have the proposed master password API or any other workaround ready until this release?  https://www.mozilla.org/en-US/firefox/organizations/
You need to log in before you can comment on or make changes to this bug.