I’m using firefox with multi container setup. I would like the ability to optionally assign an entry to a container.
E.g.
I have 3 AWS accounts: personal, client1, client2. I also have 2 firefox containers for client1 and client2. I’m using the “default/no container” for personal stuff.
It would be great if it was possible to assign the entry for AWS client2 to only autofill in container 2 and so on.
I’m not sure if this is even possible (for the kee extension to be aware of the current container name) but I figured it doesn’t hurt to ask.
P.S. I’m using a similar setup with chrome - where I have different chrome profiles for different projects. Again it would be cool if entries could be “assigned” to chrome profiles.
The “Chrome profiles” suggestion is essentially what I tried with KeeFox many years ago - you could assign a “Location” to your Firefox profile and limit KeePass entry matches using that. It never got used though, probably because it was too complex to understand, and so it has never been re-implemented in Kee.
Maybe that idea and your containers suggestion could be combined in some way to increase the usefulness enough to make it worthwhile implementing and maintaining.
What about if we created a “tag” concept, where you could assign a value to the tag based on a number of criteria:
Browser profile
Container ID and/or name and/or some other metadata we can attach to the container
Tab group ID/name and/or some other metadata we can attach to the group
Physical location
I’m not sure if the necessary browser support (WebExtension APIs) exist for 2, 3 and 4 to be possible but would be interested to hear about such support. I think 3 wouldn’t be possible at the moment without some dependency on a 3rd party extension but I think Chrome or Edge has recently added some sort of native support for tab groups so we can hope this gets implemented in all browsers and added to a future version of the WebExtensions API.
4 is what I had in mind a decade ago (home vs work) but I think even before 2020, the idea of a device’s physical location being a useful way to infer which set of passwords someone needs access to was getting rather unlikely.
We would have to either use the existing KeePass concept of “tags” to identify which entries can be considered for matching, or come up with a different name for our “tag” concept to avoid confusion. In any case, we’d need to make changes to KeePassRPC to ensure that this tag data is considered when matching entries and/or returned to the RPC client (Kee) for it to take into consideration. The latter approach may be more flexible since Kee could then do things like prioritise based upon a matching tag but still offer the alternative credentials for manual selection.
Thanks for the suggestions. I won’t have time to implement anything for a while but if you’d like to have a go at it or just help this design stage move forward, I’ll try to help out whenever I can.
The tag concept sounds awesome - it would also add an amount of future-proofing. Today is for containers; tomorrow might be for something else.
I’m sure you hear this a lot but I’m not a developer - I wish I could help with the implementation but I can’t. I’m happy to offer my sysadmin/devops skills if I can contribute with those
