Open Bug 1476755 Opened 6 years ago Updated 2 years ago

Web Extensions cannot manage saved logins for accounts.firefox.com

Categories

(Firefox :: Firefox Accounts, defect, P3)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: lisa.dusseault, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180621125625

Steps to reproduce:

After Firefox upgraded to 61.0, I was invited to create an account to setup online sync, at the URL https://www.mozilla.org/en-US/firefox/61.0/whatsnew/?oldversion=60.0.2

Attempting to create an account, first I did "Enter your Email" and Continue. Then in the next step to choose a password, I right-click in the password field  to use 1password to generate a secure password and fill it in smoothly in both fields (as well as remember it in my password vault).  


Actual results:

The password and repeat password fields are not filled in.  Nothing happens.


Expected results:

I expect both the password and repeat password fields to be filled in with the strong generated unique password supplied by my password manager, and not be blocked by the page design or code.

As a random example of where this works, if you go to https://store.usgs.gov/user/register, you can fill in the password fields (no need to fill in anything else to test the fill functionality), right click in the password field and choose 1password--> Password Generator --> Fill.  On USGS.gov and most sites, both password and confirm password are filled in with just a few clicks.  

I checked out USGS.gov working not only to provide an example of how it should work, but also to confirm that password fill does work for other sites using this version of Firefox .  Since it works, I conclude the problem is most likely with the mozilla.org Web site. 

I did not dig into what it is about the page or its javascript that might block secure password generation auto-fill.
Component: other.mozilla.org → Pages & Content
Product: Websites → www.mozilla.org
Component: Pages & Content → Firefox Accounts
Product: www.mozilla.org → Firefox
Version: Production → unspecified
See Also: → CVE-2018-5152
I expect this is caused by Bug 1415644, in which we prevented webextensions from injecting into accounts.firefox.com.  Bug 1415644 Comment 19 and down explicitly call out the main likely side-effect of this breaking third-party password managers for that page.
(Which I'll add, is a security measure, but is having the opposite effect in this case - making the user's Firefox Account *less* secure by preventing them from using good password-management hygiene)

I'm re-titling this bug to make it a generic "third-party password managers don't work on accounts.firefox.com", in case we need to dupe other bugs to it.

I'd like to understand if there's anything coming up on the add-ons roadmap that might help us allow trusted extensions to interact with privileged Mozilla pages like accounts.firefox.com. David, who is the right person for me to reach out to about that (as a low-priority request, as I know you have a lot on your plate)?

Flags: needinfo?(ddurst)
Summary: "Get a Firefox Account" page blocks secure password generation → Web Extensions cannot manage saved logins for accounts.firefox.com
Priority: -- → P3

Philipp is our product person for this, though this isn't strictly an API question. I'm also CCing amyt, because this is one of those larger policy-esque questions that is unclear who is responsible for.

From the password manager side of things, we should allow this (certainly for Firefox's built-in password manager, which is evolving out of being an extension) and password generation. Whether we would also allow this for a third-party's extension is the devil in the detail that I think is an Add-on policy question.

Flags: needinfo?(philipp)
Flags: needinfo?(ddurst)
Flags: needinfo?(atsay)

Hi Ryan, it's not currently on the roadmap but we should discuss. Opening things up would require an approval process that we might not have resources for, and making it available only to ourselves isn't ideal either.

Flags: needinfo?(philipp)
Flags: needinfo?(atsay)

Is there any way we could make this safe without allowing the full surface area of a content script? So perhaps a autofill background script API that gets an origin or something?

Hello 👋. I'm one of the Web Extensions developers at 1Password. We've had quite a few users who have encountered this issue and are willing to provide any assistance needed to find a solution that allows our mutual users to stay safe and secure while using fxa.

See Also: → 1625402

We recently ran a survey to see why people reset their Firefox Account password and if there was anything we could do to reduce that. The results surprised us. As in, we all expected the #1 answer but we didn't expect the #2 most popular answer.

I'm sharing the results here since it's important data that could help prioritize this bug.

Here are the top 2 reasons:

  1. I forgot my password (~75%)
    2) My password manager doesn't remember it (~11%)

src: https://app.surveygizmo.com/explorer/report-view/id/5622367/view/4005

If you want to get a sense of how many people represent, here is the volume of daily password resets:
https://analytics.amplitude.com/mozilla-corp/chart/dr86gbs

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: