If you're optimizing for UX you're not optimizing for security. It's just how it is.
My password manager can't communicate with anything, it's local only. It runs on a separate host so no, it doesn't have any browser integration. A browser is way too complex attack surface to trust. Only way I get a password is to ssh into the isolated host, decrypt password and cut & paste.
> If you're optimizing for UX you're not optimizing for security. It's just how it is.
Security can never be perfect. It's a lesson in trade-offs.
For example, if you make security so hard or inconvenient that people won't engage in secure behaviors, then in the end you're worse off.
This is the reason password rotation has fallen out of favor lately.
If in general we did away with password managers and took your lead, I guarantee we would collectively be worse off because, for most folks, what you describe would be seen as way more trouble than it's worth.
Your black-and-white take also fails to account for varied threat models.
Remember, the most common threat model online today is service breaches leading to passwords being exposed, followed by credential stuffing. Password managers encourage practices that eliminate that threat model.
If your threat model is centered on password manager service breaches like this one, then use a solution that doesn't require cloud hosting (e.g. keepass).
So now we need to worry about device breaches, which requires hackers to go after individual users (either targeted or untargeted), which has a much higher cost/complexity. We've made the hackers job a lot harder, which is good.
And if your model is centered on device breaches, well, bad news: your browser already sees your passwords go by (among many other things), so if the device is breached, you're hooped, password manager or no password manager.
I think about making something similar. Though the direction would be in reverse.
Say a Pinephone with no way to ssh into by default that is normally powered off. No services listening on the network running on it + strict firewall.
It can only initiate connections to other devices.
Unless I want to sign a ssh key from a CA stored on it or provide a password to some of my other devices it's just powered off. All of DRAM is cleared prior to shutdown. Pinephone can boot to UI in ~2-3s so it would not be bothersome to keep it normally off, and boot up only when needed. Battery would last months for a single charge for this use case.
It would run just a few processes. Init, maybe wpa_supplicant for wifi, and a UI process. Very simple SW, extremely limited attack surface.
Pinephone has a nice feature that it can emulate any USB device, so I could connect it over USB to any machine, and just make it look like a keyboard, and just type in the username and password into a focused field, for the password filling feature.
If I want to create a short term ssh certificate and sign a SSH key for access to a customer machine, the phone would connect to my workstation/notebook/whatever directly over ssh and sign/upload the certificate.
> A browser is too complex but an OS and SSH aren't?
Yes, most certainly.
A browser is running adversarial third party code all the time as a matter of course. While browsers do a good job at isolating, expecting this to be perfect is way too fragile for a security critical requirement like putting all passwords in one basket.
An isolated and minimized OS install, much easier to harden. Never runs any code you don't know about.
My password manager can't communicate with anything, it's local only. It runs on a separate host so no, it doesn't have any browser integration. A browser is way too complex attack surface to trust. Only way I get a password is to ssh into the isolated host, decrypt password and cut & paste.
Less convenient, sure. Also far more secure.