> In both your original reply to me and the follow up what you wrote about was storing passwords in a secret store to avoid copying them from somewhere else as that would have them go through via "a clear text protocol".
This was a complete > misunderstanding of what i wrote about.

You keep saying “passwords” then saying you’re not taking about “passwords” and then saying I misunderstood you because I mentioned passwords yet I never actually mentioned passwords. Go back and read my original reply:

https://news.ycombinator.com/item?id=30220104

Is it possible that you’re conflating “secrets” with “passwords”? Because they’re not the same. The latter is a subgroup of the former

> I am not oblivious to what benefits secrets managers would have, they are only tangentially (if at all) relevant to what i discussed about.

I know that’s not what you discussed. My point was what you discussed is a crappy solution that has already been superseded with secrets stores to solve this over arching problem space. Thus your solution should incorporate secrets stores instead of reinventing them but badly.

> you made some initial assumption about what i know

With the greatest of respect we’ve had the following issues:

1. You’ve conflated “secrets” and “passwords”. Secrets is a term in infosec that refers to more than just passwords. It’s the standard term for discussing sensitive content in this context. Which is why I’ve repeatedly used that term. And you’ve misunderstood it’s meaning completely and even made accusations that I’ve not understood that you’re describing more than just passwords because you’ve misunderstood the term “secrets”.

2. You didn’t realise that secrets stores have a TTL. That alone literally solves 80% of the problem you’ve got and does so right out of the box.

3. You conflated password managers and secret stores (ok, that one is partly my fault too because I used password managers as an example to loosely describe how a secrets store might work. But the fact I had to make that explanation is telling).

4. You forgot that browsers often use system APIs for password storage. I’m giving you the benefit of the doubt that you did know this originally (given your comment about kwallet) but you cannot deny that you did post earlier that you wanted an external API (with regards to browsers), forgetting that many do actually already do this.

5. You also claim that you know every single library that is installed on you desktop. This is at best a huge exaggeration. But realistically it’s either completely delusional or an out right lie.

I could go on. But suffice to say you’ve not exactly redeemed yourself as an authority on this topic despite being confident that everyone else is wrong.

> What i wrote about was on improving the security for clipboard-like workflows specifically, to avoid the issues the clipboard has right now without breaking any existing applications

I got that. The point you keep missing is that adding a new API breaks clipboard-like workflows anyway. So if you’re already breaking that then why not build your new API on top of a secrets store, give that data a short TTL and leverage already proven technology. The entire process can be streamlined from a user perspective so it even looks like a clipboard. Except it is secure.

> All that stuff should be obvious and i do not see why i'd have to spell them out when

What you’ve posted is obvious. The issue is you don’t understand how secrets managers work so defaulting to the position that they are clearly not suited.

Anyway, I can’t see this argument being resolved. You’re not going to research the topic and I’m not going to concede that you’re not just reinventing the wheel but badly. So maybe we just give up here?