Note that what i refer to is not about breaking any standard API but adding a secondary one that is explicitly about secret/sensitive stuff. Current applications will of course be still using the clipboard but the situation wont be any worse than it currently is and new applications as well as applications currently active development can be made to use the new one, so things can be better.
IMO this is a much better approach and way more likely to be adopted than anything that breaks existing applications and workflows.
Also while people use passwords as an example, this is just an example. What you are copying can be some secret government-issued number (that you can't replace with anything else), some sensitive photo or anything else that you want to be exact at both ends of the operation.
If the source of the data to be placed in the secure clipboard (for lack of a better name) is some encrypted storage (like a local secrets manager) or a plain text file is irrelevant here.
> Note that what i refer to is not about breaking any standard API but adding a secondary one that is explicitly about secret/sensitive stuff.
But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead?
> If the source of the data to be placed in the secure clipboard (for lack of a better name) is some encrypted storage (like a local secrets manager) or a plain text file is irrelevant here.
It’s very relevant because:
* clipboards are temporary which means you need to copy data into them. This creates an extra step for users to follow as opposed to applications querying the secrets store directly
* clipboards don’t have RBAC unlike password stores. Which means any application with permissions to read from the clipboard can read any secret that any other application had written to it. Your solution of having an additional permissions set where you chose which applications have that permission is solved with secrets store where each application only has permission to the secrets it creates. Thus zero risk of leakage
* secrets managers are encrypted, clipboard isn’t
* secrets managers can store multiple secrets, a clipboard cannot. Thus you then still need to have a secrets manager to copy your password into the clipboard anyway. So why not do away with that middleman entirely?
I get the incentive of wanting to “fix” the clipboard but if you’re going to introduce a new API for secrets then you might as well do it properly from the outset.
> But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead?
Because the entire point of this is NOT to store something but to transfer something from one application to another without both applications explicitly knowing about each other (so they can't just communicate in a P2P fashion). The rest of your message is about storing data, which is not what the clipboard use is all about. Which is why i wrote it is irrelevant - you refer to something else.
E.g.
> clipboards are temporary which means you need to copy data into them. This creates an extra step for users to follow as opposed to applications querying the secrets store directly
The API i mention is not about permanently storing data, it is explicitly about having a secure temporary store with the same(ish) UX as a clipboard but for secure data.
Applications can also use a secure store for that and the data that is being copied to the secure clipboard could also come from an application that stores its own data to it from there, but again this is a separate issue, this is orthogonal to what a discuss here.
> secrets managers are encrypted, clipboard isn’t
This is irrelevant as the data isn't stored elsewhere outside the memory of the process that would manage the secure clipboard's functionality (and of course you could encrypt that if you'd like but IMO that'd be pointless since it'd need to be decrypted at some point anyway and these would be meant for temporary storage - regardless of you do or not encrypt it though it'd be again orthogonal to the rest of what i describe).
> secrets managers can store multiple secrets, a clipboard cannot. Thus you then still need to have a secrets manager to copy your password into the clipboard anyway. So why not do away with that middleman entirely?
Because this isn't about storage.
> if you’re going to introduce a new API for secrets then you might as well do it properly from the outset.
That'd be a "proper" solution for a different problem, hence barely a solution at all.
I get that you’re not storing something long term, but you are still storing it even if it is short term and thus presenting a risk. And you are still sharing secrets between applications thus presenting a risk. And all your suggestion is doing is offering a kludge around a solution you’ve already said is crappy, rather than switching to a robust and battle tested solution that literally every other platform already supports.
If you want to pass secrets securely between applications then you use a secrets manager. It’s how Linux and macOS work. It’s how secure systems in the cloud works. And thus it makes complete sense for Windows to follow suit. We aren’t talking about some theoretical concept here. It is absolutely how passing secrets between applications should be done.
If you have scepticism about this approach then you need to read up in this topic rather than pushing for a half baked kludge around something you’ve already acknowledged isn’t fit for security.
Sorry if this sounds blunt but this is a solved problem you’re trying to re-engineer and your solution is worse than the industry standard in a number of ways which I’ve already highlighted. And ironically it isn’t even just worse for security but also worse for usability well (you’re creating administrative overhead with the user approving safe applications. This wouldn’t be needed with a secrets manager since each application only has visibility of its own enclave). And if you remember back to your first post, usability was the entire reason you designed this solution in the first place.
I do not know why you mention Windows, i never referred to any specific platform (you mention Linux, Linux does not actually have what you describe because Linux is a kernel and what you describe is something that would live on the userland - the userland heavily relies on what software is installed and many setups, like mine, do not have such a thing).
What i refer is how to provide a more secure approach to to THE SAME THING that people are already doing with clipboard copy/paste without breaking the versatility of the clipboard, workflows or even existing applications and can be supported with minimal changes in existing applications and pretty much zero re-learning by users. It is about being able to copy/paste stuff securely anything that can already be copy/pasted between applications and not just passwords or other stuff you'd need to store permanently. It can even be made to work in a backwards compatible way - with some additional though minimal effort from the user - for applications that do not support the functionality.
What you refer to is having a different workflow, have applications add explicit support for the specific data mentioned and be accessed in a different way and up to the last reply you were referring to permanent storage.
You ask people to change how they use software, i ask them to use a different menu option for sensitive stuff. What exactly do you think is the more likely to happen?
(well, assuming anything would happen, in practice most likely nothing will change)
I do not have skepticism about what you refer to, i do not even think what you refer to is wrong for the stuff it is intended for, i am just not referring to the same stuff you do.
> I do not know why you mention Windows, i never referred to any specific platform
Because this is already a solved problem on all popular platforms aside from Windows.
Plus others earlier in this discussion singled Windows out too (likely for the same reason I cited above).
> Linux does not actually have what you describe because Linux is a kernel and what you describe is something that would live on the userland - the userland heavily relies on what software is installed
It’s pretty normal for people to talk about Linux as a computing platform. You know this yourself so making the “it’s just a kernel” argument is next level pedantry.
> and many setups, like mine, do not have such a thing
I’d put money on you having one installed and not even realising it (eg gnome-keyring, which is a dependency for many desktop applications even without having gnome installed)
> What i refer is how to provide a more secure approach to to THE SAME THING that people are already doing with clipboard copy/paste without breaking the versatility of the clipboard
I understood what your approach was. The issue isn’t that I don’t understand it. The issue is that you are unwilling to accept the last 20 years of development in this field.
I mean have you never even used password management in Firefox / Chrome? Avoiding the need of clipboard for sharing secrets is a security and usability feature. Your solution is terrible in comparison and this is precisely why browsers have integrated password stores.
> What you refer to is having a different workflow, have applications add explicit support for the specific data mentioned and be accessed in a different way and up to the last reply you were referring to permanent storage.
Your solution was to add a new API. You stated that explicitly. You then said users should authorise which applications have authority to use that API, that’s a new workflow too. The standard approach (ie that way the industry works, this isn’t something I’ve just made up) allows applications to communicate directly to your secrets store. This doesn’t add a new workflow, it removes an existing one entirely.
Plus you still need to copy your passwords from somewhere to use your API so why bother with it in the first place? It’s literally just adding in a process for the sake of it. Except that process is insecure, a usability nightmare and contradicts decades of established solutions in this precise domain.
The fact that you’re refusing to even look into this concept is astonishing tbh
> am just not referring to the same stuff you do.
indeed, your stubbornly clinging onto a terrible idea and rejecting decades of industry best practices.
The idea you’re proposing has already been superseded by years of research and development towards much better solutions. And you can install them right now if you wanted. I’m not making this shit up.
> It’s pretty normal for people to talk about Linux as a computing platform. You know this yourself so making the “it’s just a kernel” argument is next level pedantry.
In this case the "pedantry" makes sense because...
> I’d put money on you having one installed and not even realising it (eg gnome-keyring, which is a dependency for many desktop applications even without having gnome installed)
...i do not have such a thing. I use plain Xorg with Window Maker and i have removed anything i deemed unnecessary from my PC.
> The issue isn’t that I don’t understand it.
No you do not understand it because you wrote:
> I mean have you never even used password management in Firefox / Chrome? Avoiding the need of clipboard for sharing secrets is a security and usability feature. Your solution is terrible in comparison and this is precisely why browsers have integrated password stores.
My solution is to *NOT* use the clipboard *exactly* because it is not secure for the reason mentioned in the *linked article*! Which is why i mention a *second* API to exist *alongside* the current one. The only reason i use the term "clipboard" is because from a usability perspective (for both the users and, for the most part, the programmers) the use will be the same so it is the closest to understand.
> Your solution was to add a new API. You stated that explicitly.
Yes i did. I explicitly wrote that new applications can use it, existing applications can be made to support it and with some minimal effort from the user even existing applications that do not support it can be made to do it.
> You then said users should authorise which applications have authority to use that API, that’s a new workflow too.
No i never mentioned that, in fact i never even mentioned how that part would work. Here, this is what i originally wrote: "that you can lock as tight as you want with explicit permissions for reading it, notifications for writing to it and whatever else you want."
> The standard approach (ie that way the industry works, this isn’t something I’ve just made up) allows applications to communicate directly to your secrets store.
Because...
> Plus you still need to copy your passwords from somewhere
...i do not...
> to use your API so why bother with it in the first place?
...refer to just passwords.
This is about *ANYTHING* that can go on the clipboard that can be sensitive. This is about stuff that is temporary. *THIS IS NOT ABOUT PERMANENT STORAGE*.
I already wrote that stuff, gave examples and yet you claim that i am the one who is "stubbornly clinging" to my idea.
How about following the HN commenting guideline about "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith" and using your imagination to try and understand what i refer to instead of calling me stubborn?
If you do that you may realize that what i describe isn't even incompatible with secure stores and can be functionality that is provided by them.
> ..i do not have such a thing. I use plain Xorg with Window Maker and i have removed anything i deemed unnecessary from my PC.
So you don’t use a web browser then? I guess your posts here must appear by magic.
> This is about ANYTHING that can go on the clipboard that can be sensitive.
Hence why I’ve repeatedly used the term “secrets” and not “passwords”.
The password manager example was just an illustration because this entire concept seemed weirdly alien to you. But secrets stores are not just for passwords and nor do they need to hold secrets for long durations either.
Again, I implore you to actually do some reading on this topic before making daft assumptions. Look into Hashicorp Vault for example. Now I’m not suggesting everyone should manage their own Vault instance; but if you’re going to create a new API anyway then you might as well abstract that around similar tooling which is managed by the OS rather than configured by the user. I mean why reinvent the wheel (and badly too) when this approach is proven?
> How about following the HN commenting guideline about "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.
You mean like your pedantry about Linux being a kernel when you knew full well the context that term was used in?
Your ego here is getting in the way of you learning some new technology (well, I say “new” but it really isn’t). This is already the direction the industry has already moved.
> So you don’t use a web browser then? I guess your posts here must appear by magic.
Of course i use a web browser. What i do not have is a generic store like the one you describe - my web browser does not provide an API for other applications in my desktop to access whatever is stored in it.
> Hence why I’ve repeatedly used the term “secrets” and not “passwords”.
And yet you used them explicitly for storing passwords.
> The password manager example was just an illustration because this entire concept seemed weirdly alien to you.
...that i do not refer to just passwords but anything that can be copied to the clipboard and passwords was just an example.
That you think that "concept seemed weirdly alien" to me can only be seen as an indication that you do not read what i write.
> You mean like your pedantry about Linux being a kernel when you knew full well the context that term was used in?
As i already wrote previously, that part was to make it clear that this isn't something you can depend to be there "on Linux" because not everyone's setup has one - like mine.
> Your ego here is getting in the way
Does it really? From my perspective you entered the discussion with a polemic tone and when i tried to explain my position you doubled down, ignoring what i wrote and even started writing that i do not even know what i have installed on my own computer.
> Of course i use a web browser. What i do not have is a generic store like the one you describe - my web browser does not provide an API for other applications in my desktop to access whatever is stored in it.
Well that actually depends on the browser and OS. You’ll find some browsers actually use an existing system API for their password store.
But anyway, I wasn’t suggesting the final solution be a password manager. I just exampled that because you seemed oblivious to the benefits a secrets manager would have and password managers share an overlapping domain.
> > Hence why I’ve repeatedly used the term “secrets” and not “passwords”.
> And yet you used them explicitly for storing passwords.
Not just passwords. Any secrets. I’ve repeatedly said secrets and not passwords. Those secrets could be a password but they could also be private keys / certs and even just sensitive config. I’ve literally used secrets managers for these things too. And it is extremely easy to store any kind of secret because at the most basic level they’re just key value stores with a TTL and encrypted storage engine and secure API for 3rd party applications to query. Literally the end solution one would come to if they took your specs and fleshed them out to a secure and robust natural conclusion.
So yeah, you can put in any data you want.
You’d also know this if you spent even just 5 minutes researching this like I’ve repeatedly suggested.
> you explicitly refer to "password stores".
Yes, as an example of utility because you couldn’t grasp the concept and was too lazy to do any research.
Now that you’ve wrapped your head around the basics go look up Hashicorp Vault and you’ll get a sense for how a secrets manager is much more than just a password manager.
Now think about how that solution could be utilised to solve the same problem you’re identifying. And you’ll finally understand why I keep harping on about it.
> i refer to "copying data" and even if it is in the context of passwords, i make explicit in the very first reply i made to you:
Again, secrets stores aren’t just for passwords.
> That you think that "concept seemed weirdly alien" to me can only be seen as an indication that you do not read what i write.
I’ve been listening to you. But frankly communicating with you is like trying to draw blood from a stone because you keep insisting on having an opinion on a domain you clearly know Jack shit about and then refusing to spend even the smallest amount of time looking into any of the technologies being recommended.
The issue here is 100% you, not me. I build and use these technologies for a living and you clearly haven’t the foggiest on this topic.
> As i already wrote previously, that part was to make it clear that this isn't something you can depend to be there "on Linux" because not everyone's setup has one - like mine.
You could also not install support for the hypothetical API you’re imagining too. So your point here is moot.
This is why I was using Windows as the baseline for the conversation. It saves us from these stupid meta hypotheticals about “what if I chose not to install this thing I just moaned about wanted to install”…
> when i tried to explain my position you doubled down
You tried to tell me that 20 years of security technology didn’t exist. So yes, I did double down on the fact that you were wrong because you were and still are.
Also I love the hypocrisy of the statement that I’m “doubling down” and you’re just “explaining your position”. The way I saw it, you posted an idea, I came up with a better solution and you then doubled down that your crappy alternative was better for reasons and then posted a list of misunderstandings.
You’ve also pulled this hypocritical shit a few times too, accusing me of doing the very things youre already doing.
> ignoring what i wrote
I addressed your points literally. If you’d spent even 5 minutes researching this field you’d realise that.
And I’ve lost count of the number of times I’ve asked you to read up on this topic. It’s not an unreasonable request on my part.
> and even started writing that i do not even know what i have installed on my own computer.
Given you don’t even know what this technology is, I find it hard to believe that you’d know if it was installed or not.
Plus as a Linux developer and sysadmin myself, I know full well that it’s impossible to audit every single package that goes into a desktop installation (a minimal headless image is possible but not a multi-purpose desktop installation). And I’m the kind of person who has spent decades compiling frameworks, drivers and desktop software from source so if I can’t memorise every single dependency then there’s no hope for you. The fact you think it is possible honestly says more about where you sit on the Dunning-Kruger scale than it does about me.
Honestly, drop the ego and look this stuff up. It’s pretty cool technology. It wouldn’t suit your needs perfectly in its “off the shelf” state but it is the backend architecture that would best realise your vision. But until you do any research of your own you’ll find that we will just keep going round in circles.
> Well that actually depends on the browser and OS. You’ll find some browsers actually use an existing system API for their password store.
Right, but mine doesn't and you referred to my browser.
> But anyway, I wasn’t suggesting the final solution be a password manager.
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.
> I just exampled that because you seemed oblivious to the benefits a secrets manager would have and password managers share an overlapping domain.
I am not oblivious to what benefits secrets managers would have, they are only tangentially (if at all) relevant to what i discussed about.
> Not just passwords. Any secrets. I’ve repeatedly said secrets and not passwords.
You kept referring to passwords and how storing the passwords in a secret store and have it be accessible by the application would be better than having passwords be passed via a secure clipboard - which is completely and absolutely missing the entire point of what i was discussing about.
> So yeah, you can put in any data you want. You’d also know this if you spent even just 5 minutes researching this like I’ve repeatedly suggested.
Yes, of course i know that, if you weren't so sure about your preconceived notions about the other person you are making a bad attempt at discussing with, you'd actually have realized that.
If you also made an attempt to understand what the other person writes about you'd also realize that i also refer to having applications pass data in an encrypted way and not just passwords, despite you claiming that i did not understand that and this is why you "exampled that because i seemed oblivious to the benefits a secrets manager".
The other interpretation however is that you refer to something different that just sound similar because they both have to do with using passwords.
> I’ve been listening to you.
It doesn't feel that way at all.
> But frankly communicating with you is like trying to draw blood from a stone
But that is how i feel.
> The issue here is 100% you, not me.
From my perspective you are the one at fault for not even trying to understand what i was referring to. Thing is i know what your issue really is, you made some initial assumption about what i know (that you keep repeating) and what i was referring to and try to filter everything you read from me through that assumption. I mean you even spelled out here:
> Given you don’t even know what this technology is
I know what you'd like applications to do and where to store their secret information and how to work - as you wrote this isn't new technology and in fact personally i first used it in the early 2000s in KDE with KWallet and later with GNOME 2. But i never felt like bringing up (my) credentials or bringing up any experience i had with these because, from the very beginning, i knew that these have nothing to do with what i referred to.
When i wrote that these are irrelevant i didn't write it because i didn't knew what they are, i wrote it because they actually are irrelevant to the original idea i described. Yes, if an application wants to store and then use and retrieve secrets (be it passwords, documents, photos or whatever), either stored by it or by another trusted application, a secrets manager would be preferable.
But i wasn't referring to that use case. What i referred to didn't even had the same way of interaction with the applications. 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 (e.g. clipboard managers - remember that other comments in the thread were about how to make "clipboard snooping" impossible, which would certainly stop those from working).
All that stuff should be obvious and i do not see why i'd have to spell them out when i keep writing that secure stores are only tangential to the examples i give and not what i write about.
And honestly...
> Honestly, drop the ego
...if after being confronted with someone claiming that what you keep on writing about is irrelevant to what they were referring to has you thinking as the only possibility for that is that they lack (your) knowledge and not you who might not trying to see things from a broader perspective, then i'm not sure who'd be the one with the ego issues.
> 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:
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?
> 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.
You also keep using the word "password" while claiming you are not using the word "password" like you did right now.
And of course what i just wrote, just like what you just wrote, is not an argument at all since this isn't about the existence of the word "password" in the text that was typed, but of what you are claiming.
From the very beginning i only used passwords as an example of something that can be placed in the secret clipboard. In the first reply to you i already made that clear - which is also something i pointed out in another reply later.
> Is it possible that you’re conflating “secrets” with “passwords”? Because they’re not the same. The latter is a subgroup of the former
Please read what i write, i do not conflate the two and this should have been obvious from the first reply i made to you where i write that the source for the data to be placed in the secure clipboard can come from a secrets manager.
> 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.
And this is why you do not understand what i wrote. Secret stores do not solve the same problems that the secret clipboard i described does.
> 1. You’ve conflated “secrets” and “passwords”.
As i already wrote, i did not, you just made that assumption. Even if i had no idea what they'd be it'd be a very stupid mistake to make since the name is practically self-describing in context.
> 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.
This has nothing to do with what i describe, aside perhaps from using it as a way for a secrets manager to implement the secure clipboard API - like i already mentioned several replies ago in https://news.ycombinator.com/item?id=30220474
> You conflated password managers and secret stores
I did not, i only brought up password managers as an example which i quickly made clear that they were only just one source for the data to be placed in the secure clipboard in the first reply i made to you.
> But the fact I had to make that explanation is telling
It is only telling that you do not bother to read and understand what the others are writing.
> You forgot that browsers often use system APIs for password storage.
...no? I never forgot anything like that, this is again an assumption you made. The only time i referred to a browser was for my browser and i already wrote that i only did to that, not to any potential browser that could exist. I have used other browsers in the past, like Safari, that does use system APIs for password storage (or at least that is what i assumed Safari was doing, i never really digged down on that).
> benefit of the doubt
Instead of trying to doubt me, you may actually want to try and understand what i am writing.
> but you cannot deny that you did post earlier that you wanted an external API (with regards to browsers)
What i describe is a different API because the functionality i describe is not the same as what a secrets store would provide. This is what i am trying to explain from the beginning.
> 5. You also claim that you know every single library that is installed on you desktop.
I never claimed such a thing, this is yet another assumption you make.
The only thing i claimed was that my setup does not have a secrets manager that other applications can use, like you originally described "Linux" having. Which is why i wrote what you took as pedantry, that Linux isn't just a single setup and setups without a secrets manager do exist - and brought up mine.
While i do not know every single library that is on my system, i do have a decent idea on what is in it there since i try to pay attention to what i install.
So unless you consider having libsqlite3 and libgcrypt available as shared objects passes as a secrets store API that applications can use (they can always pester me for a password/something every time they need to access the data), i am certain i do not have one.
> suffice to say you’ve not exactly redeemed yourself as an authority on this topic
I never claimed to be an authority on this topic either. In fact if you were to ask me, i'd be the first one to say i do not really know much about security (and it isn't really a topic i am interested), which is why i mainly focused on the functionality from a UX perspective and how people would use it rather than how the underlying system would be implemented.
> The point you keep missing is that adding a new API breaks clipboard-like workflows anyway.
It doesn't, the existing clipboard API would still be there. From the very first comment i brought that up, i mentioned that the secret clipboard would exist alongside the existing one as to not break anything that currently works.
It is even right after the bit you quoted in your first reply to me.
Here: "IMO a better solution that wouldn't break existing clipboard usage is to have a second "secure" clipboard that you can lock as tight as you want. Then password managers would copy data to that and text editors and browsers can have a "Copy Sensitive Data" (or something better worded) in addition to "Copy" that will place data there.
In fact...
> why not build your new API on top of a secrets store, give that data a short TTL and leverage already proven technology.
...I even mentioned in another reply that what you describe could implement the API i describe.
> The entire process can be streamlined from a user perspective so it even looks like a clipboard.
Yes, like i already wrote in my original message: making something that, for lack of a better word, is essentially a "secure" separate clipboard, something that looks and behaves like a clipboard. The never specified how it would be implemented, only how it'd behave. I only wrote "lock as tight as you want with explicit permissions for reading it, notifications for writing to it and whatever else you want". I left the implementation up in the air.
Would it be implemented by a secrets store or some other service that communicates with a secrets store and sets up some low TTL or outright destroys the data after it has been pasted? Doesn't matter, it wasn't what i was describing, that would be some implementation detail.
Which is why i kept on and on and on and on repeating over and over that what i describe is not about secrets stores and is irrelevant, aside from perhaps having one implement it.
> The issue is you don’t understand how secrets managers work so defaulting to the position that they are clearly not suited.
I understand what they are used for and what they are used for is not for the functionality that i describe (there might be one that does have something similar that i do not know about but as i do not know it, i only refer to the concept in general), otherwise i wouldn't bring up the idea in the first place.
> 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?
If you are so hellbent in avoiding to understand what i write, sure, it doesn't sound like there is a reason to continue.
IMO this is a much better approach and way more likely to be adopted than anything that breaks existing applications and workflows.
Also while people use passwords as an example, this is just an example. What you are copying can be some secret government-issued number (that you can't replace with anything else), some sensitive photo or anything else that you want to be exact at both ends of the operation.
If the source of the data to be placed in the secure clipboard (for lack of a better name) is some encrypted storage (like a local secrets manager) or a plain text file is irrelevant here.