fix: firefox suggesting unlock passcode on nostr private keys

[fczuardi]

Describe the changes you have made in this PR

Hints Firefox password manager that the Nostr private keys are not password for the same (no user) that is the unlock password.

Link this PR to an issue [optional]

Fixes #2489

Type of change

• fix: Bug fix (non-breaking change which fixes an issue)

How has this been tested?

On Firefox (Linux) I have set up 3 accounts with 3 different nostr private keys, later I opened about:logins and searched for "moz". Firefox didn't replace my unlock passcode, the password for the (no username) user.

Checklist

• My code follows the style guidelines of this project and performed a self-review of my own code
• New and existing tests pass locally with my changes
• I checked if I need to make corresponding changes to the documentation (and made those changes if needed)

[github-actions]

🚀 Thanks for the pull request!

Here are the current build files for testing:

• chrome.zip.zip
• firefox.xpi.zip
• opera.crx.zip

Download and unzip the file for your browser. Refer to the readme for detailed install instructions.

Don't forget: keep earning sats!

[reneaaron]

But you still want to be able to save your nostr key in the password manager, is that right?

[fczuardi]

But you still want to be able to save your nostr key in the password manager, is that right?

Yes, the password manager will still be able to save the nostr private key of an account as a password, however now it will use the account name as the username, instead of the (no username) user.

In other words: the Firefox password manager will still save your nostr private key as a password if you choose to, and it will not overwrite the existing unlock passcode as it did before.

[bumi]

interesting! great find @fczuardi wow.

it sounds like a bit of a strange FF behavior.
@reneaaron any objections to merge this?
@fczuardi maybe we can add a link to the issue in the comment.

[fczuardi]

interesting! great find @fczuardi wow.

it sounds like a bit of a strange FF behavior. @reneaaron any objections to merge this? @fczuardi maybe we can add a link to the issue in the comment.

reference to the issue added

[pavanjoshi914]

hey @fczuardi thanks for making up the PR. we had a lot of changes in Alby screens the past few days. so I decided to make a new pr. we corrected the autocomplete problem on all the password fields that firefox is causing. closing this in favour of #2595.

[fczuardi]

Hi @pavanjoshi914, I remember we tried the autocomplete new-password path and the issue persisted, that's why our approach was the hidden field path. But I can try to reproduce it on my Firefox and your branch tomorrow and let you know if we should reopen the issue or not.

…

-------- Original Message --------

On Jul 28, 2023, 06:17, Pavan Joshi wrote: hey ***@***.***(https://github.com/fczuardi) thanks for making up the PR. we had a lot of changes in Alby screens the past few days. so I decided to make a new pr. we corrected the autocomplete problem on all the password fields that firefox is causing. closing this in favour of [#2595](#2595). — Reply to this email directly, [view it on GitHub](#2497 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAB4UDI7FEOLHPEMAWGSZ3XSN7TNANCNFSM6AAAAAAZMSWFQI). You are receiving this because you were mentioned.Message ID: ***@***.***>

[pavanjoshi914]

thanks for helping out there! please do test and let me know! on my side. issue is resolved for firefox password manager as well. let me know if issue persist on your side

[pavanjoshi914]

where did you tried new-password field? on form level or on text field?

[fczuardi]

Hi @pavanjoshi914 I just confirmed on the master branch (that have your patch) and Firefox+Linux the issue is still reproducible. Entering a Nostr private key on the Nostr Settings and accepting the Firefox prompt to save the password, it will overwrite the saved unlocking passcode (the password with "no username" in the password manager), see screenshots below:

[pavanjoshi914]

we use new-password on all the fields except unlock field. even if you save nostr private key in pasword manager. it will not autocomplete the field. in the nostr text field. as it will always default to new-password. the current discussion was to just disable autocomplete for all other fields or don't allow any saving feature on other fields. and only accept auto-complete for unlock fields.

if we use the hidden field on nostr private key. it will also disable autocomplete feature. then why to save private key in password manager?

regarding unlock fields, we don't put any restrictions there. probably we can disable autocomplete there as well. cc @rolznz @reneaaron @bumi

[fczuardi]

The password manager wont autocomplete the nostr private key field, that's correct. But if someone accepts the firefox prompt asking to save the password (by accident or by habit) on the settings page it will overwrite the unlocking password with nostr private key.

Issue #2489 was indeed about the other way around (unlocking password getting autocompleted on nostr field) and that is not happening anymore. However, after the fix we now have a new problem: nostr private key getting autocompleted on the unlocking passcode field.

Should we open a new issue then? instead of reopening #2489 ?

@pavanjoshi914 do you see my point? What my screenshots shows is that a value that is not the unlocking passcode value being completed on the unlocking passcode field. (because Firefox have only one "no username" password per domain).

The statement below is not true:

if we use the hidden field on nostr private key. it will also disable autocomplete feature.

It wont.

[pavanjoshi914]

The password manager wont autocomplete the nostr private key field, that's correct. But if someone accepts the firefox prompt asking to save the password (by accident or by habit) on the settings page it will overwrite the unlocking password with nostr private key.

regarding unlock fields, we don't put any restrictions there. probably we can disable autocomplete there as well