Yes, but I'm more worried about a flaw in the software revealing my DB than phishing, something I am an expert on.

I also have some measures in place to detect. (Ex: hard coded lists of URLs that open in a "financial" container)

I don't claim it's perfect, but it's my way of doing things, I like it, and I don't think it opens me up to an unreasonable amount of risk.

(Also, for lower-value passwords, like netflix, HN, etc I just use my browser's built in password manager.)

LastPass did this wrong, they had a bug in their url parser that let you trick it into selecting the wrong site data to form-fill with.

With the c+p workflow, you can completely cut out any attack vectors (because the website doesn't interact with your password manager in any way).

you can't cut out phishing. IDN homoglyphs used to be an easy way to get burned. AFAIK this is now prevented at least by mainstream browsers (those for which a pw mgr plugin would exist anyway). 'rn' vs 'm' is still a multi-letter homoglyph that works and is very very difficult to identify.

I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?

You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.

Timing is good on this one: https://arstechnica.com/information-technology/2019/02/behol...

I didn't investigate in detail but it appears that it is a fake iframe. Even X-Frame-Options et al to prevent 3rd party iframe doesn't solve it because the iframe is fake to begin with!

Very very hard for you to prevent copy/paste to a fake iframe SSO.