Mainly internet accounts accessed via a web browser, plus other internet apps (e.g. NHS which needs logging into every time, plus I imagine Reddit/Facebook/etc if I used apps for them). I need the same credentials database on my desktop computer, so having it all stored in SFOS secure database/vault (via the browsers built-in password manager) isn’t really viable, especially if I wish to use more than one browser (e.g. Android’s Firefox).
For web you have password manager in browser, try password managers in android ff nightly, it allows more plugins than main (so bitwarden/1pass etc should be an option), still not a thing for OS feature request?
Edit: oh if you wish more than one browser sure one plugin won’t work, but seeing how native browser doesn’t support plugins you’re asking to build OS level plugin for all possible browsers kek, and for what exactly, your web browser passwords, try the android plugins
@throwaway69
Either you’re not understanding my point, or I’m not understanding yours, so I’m calling it quits, but I stand by what I’ve said. I don’t see any decent solution than some way to allow OS integration with a password manager. EDIT: See KeePassDX’s Magikeyboard for an example of what I’d like.
1 Like
There is none, is your iOS keepig all passwords for all possible browsers and terminal and any qml app? No, it’s absurd, what you’re asking is absurd and even apple couldn’t figure it out
Wanted to try your magic super sikret keyboard but trying to enable it gives: Attention, this input method may be able to collect all the text you type, including personal data like passwords and credit card numbers. It comes from the app… I’m gonna pass, not really sure why anyone would click OK here, but you do you
No, KeepassDX is. And because android has the option to set a global password manager, keepass is able to detect the app id and show password suggestions in the keyboard or as a dropdown under the input field.
I don’t understand all this discussion about use-cases. Not everyone has the same use-cases. I also have many passwords that I do mainly use in the browser, but they’re stored in a keepass db. I’m not going to use an integrated browser password manager when I already have a far superior one.
6 Likes
That’s only the auto-type functionality that does that. Regular password managers like 1password (without the typing integration), keepassdx, bitwarden, etc. don’t need this access.
I use ownKeepass which has a useful (if still manual) option to copy credentials from the cover, and this has never happened to me.
1 Like
I also do miss the functionality of Autofill and I also do Like the ownkeepass app.
If I saw it correctly the Developer is Not active anymore and the App has not been actively developed for a Long time (the Repo Seems also to be Archiven? - please correct me if im wrong)
When I have time I can have a Look and try to Implement this Logic (Autofill credentials from OwnKeePass when you try to Login into an Account at the Browser) on top of it but if we dont have Access to the Repo and Publish-Account we do have as only Option to fork the Repo and publish it under another Name…
If someone from the other developers here is willing and has some time left to implement it beforehands, please do so 
Please keep in mind that wayland is way stricter with apps (or rather windows) accessing each other.
Not without reason is this usually solved with browser addons.
In other words, this is also a security issue.
On my laptop (Xorg, not wayland) I use a global hotkey to make keepassxc fill passwords - how would that work on a phone?
Ownkeepass is maintained in the Sailfishos Chum community org at GitHub, and latest releases published via the Chum community repo:
Please collaborate there and do not fork needlessly.
5 Likes
Ah Great! Thats what I Searched for. Will collaborate there.
Some months ago it seemed to be Archived but if it’s Active again and someone is there to approve PRs than im Fine with it 
2 Likes
And before we start implementing, NiH-ing, and reinventing wheel-shaped stuff, in case you’re not aware there’s an API specification for these kinds of things:
Would be nice if any implementations used that, so apps can interoperate potentially.
KeepassX(C) already support this.
4 Likes
There are so many ways this could be implemented (with OS support), it’s hard to know what to mention. A few examples:
- A special button on the software keyboard invokes autofill from your password manager of choice. This would be the easiest for the user, but I think the hardest to implement.
- A special button on the software keyboard opens your chosen app, passing it info about the active app (probably your web browser), along with some simple API for it to return text that will be auto-typed as if it came from the keyboard. If the app was a password manager, you would likely need to search for & find the appropriate credentials entry & then tap which part of the credentials you wanted (e.g. password). On Android you can share your web browser’s current URL with an app, such as KeePassDX, which avoids the need to search for the credentials entry.
- SFOS could allow the standard keyboard to be switched with a 3rd-party one (ideally using a special button). That alternative keyboard would need to be trusted of course, and could potentially be provided by your chosen password manager as a way to enter details from your chosen credentials using special buttons (e.g. username, password). KeePassDX does this using Magikeyboard, which doesn’t even provide a real keyboard, just buttons to paste your credential details, after which you switch back to your normal keyboard.
- @nephros mentions a Secret Service API (which other password managers may support). SFOS could use this to allow directly searching & entering username & password from the built-in keyboard, without risk of 3rd-party apps doing something, but the downside is it may not support TOTP codes & other info that may not be supported by the Secret Service API.
- etc
I personally favour SFOS initially just supporting 3rd-party keyboards, as that would support a much wider use case than password entry, while also allowing any/all of my above suggestions to be implemented as part of an alternative keyboard (i.e. no need for further support by the OS, probably).
2 Likes
SFOS does support ‘third-party keyboards’.
Or at least modifying and extending the built-in one in various ways.
Just look at the DSNote keyboard, or the color Emoji patch.
Just like DSNote calls a daemon do voice processing, you could make one which interacts with a password store.
Another way could be to patch Silica’s PasswordField to add a function to retrieve secrets.
But that’s more hackish probably.
2 Likes
I researched a Little Bit and what sounded good to me was the following architectural Design:
- For „Auto-Fill Functionality: Maliit-Keyboard-Plugin (“ownKeepass-Keyboard-Row”) + D-Bus-Service in ownKeepass
- for PW sharing with other Apps and Even Command line: freedesktop Secret Service API
If we implement the freedesktop API only it will Not Solve the Autofill „Goal“, but a combination of Both together Looks promising to me.
Maliit Keyboard Plugin sounded good to me because you navigate into the Login Field, press the extra custom key (we create with the Plugin) from Standard Keyboard, you can pick the Right Entry from keepass and Autofill will do the Rest - no implementation in other Apps needed, works with all Apps.
4 Likes
Going through the laundry list of iOS apps to replace, before making the jump, I arrived at the password manager. My Keychain service contains about 1,000 entries. One third of which I used in the last handful of years.
Auto generate with complexity options, biometric unlock, auto fill-in, cloud sync. Habits settled in more than a decade of service use and thus, now, needs.
Side note: why password managers with sync services are so expensive? Costs about the same to rent 200 GB of encrypted cloud storage and to store 1 MB or two of passwords. Client has far stricter security requirements for sure. Still seems steep to me.