You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, my understanding is that passff matches urls to passwords using only metadata stored in the path of the password file. In my experience this mechanism often suggests the wrong password files, so I often have to manually select my desired password from the bottom of the list. I think it would be desirable to provide some other mechanism to help passff match a given url to the most likely password file.
I'd like to propose a feature to optionally maintains a database in the plugin that caches which password file is matched to a given url. When the feature is enabled, the plugin would then match passwords for a given url ordered first by how often the user selected the password for the url in the past, and second by the existing matching mechanism.
This can be as simple as a table in an sqlite database that stores the url (sans query string), matched password file, and the number of times the user selected the url-password pairing. The url entries in the database could be easily hashed to avoid storing this metadata on the user's computer in plaintext.
I found previous discussions that address the same topic of url metadata, but proposed different solutions.
URL Matching: use metadata files to store fields like 'url' #375 proposed using unencrypted database files to store things like url metadata in the passwordstore database. This proposal instead intends to store the url-password matching metadata in the plugin itself.
Use URL field in password data for matching #374 and Index all password store meta urls on passff init #402 implemented indexing the full password database in browser memory by decrypting all .gpg files. This index is built up on every new startup of firefox, and can take very long for large password databases. The difference with this proposal is that the mapping is persists between browser sessions and does not require decrypting the full password database. As such there is less possibility of leaking sensitive information in the database by incorrectly parsing the metadata.
I don't have any experience working on firefox plugins so I don't have a full handle on what this would require or its feasibility. I would find a feature like this immensely useful, so I would consider contributing time to work on this, if this is something that would jive well with the plugin.
The text was updated successfully, but these errors were encountered:
I think it's feasible, but it's probably a bit unstable when renaming entries, reinstalling etc. So far, PassFF is a quite minimalist wrapper around PassFF without too much additional logic of its own.
I don't have time to implement this, but if somebody comes up with a PR, I will be happy to review and merge.
Currently, my understanding is that
passff
matches urls to passwords using only metadata stored in the path of the password file. In my experience this mechanism often suggests the wrong password files, so I often have to manually select my desired password from the bottom of the list. I think it would be desirable to provide some other mechanism to helppassff
match a given url to the most likely password file.I'd like to propose a feature to optionally maintains a database in the plugin that caches which password file is matched to a given url. When the feature is enabled, the plugin would then match passwords for a given url ordered first by how often the user selected the password for the url in the past, and second by the existing matching mechanism.
This can be as simple as a table in an sqlite database that stores the url (sans query string), matched password file, and the number of times the user selected the url-password pairing. The url entries in the database could be easily hashed to avoid storing this metadata on the user's computer in plaintext.
I found previous discussions that address the same topic of url metadata, but proposed different solutions.
I don't have any experience working on firefox plugins so I don't have a full handle on what this would require or its feasibility. I would find a feature like this immensely useful, so I would consider contributing time to work on this, if this is something that would jive well with the plugin.
The text was updated successfully, but these errors were encountered: