[badsectoracula]

> 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.

[laumars]

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.

[badsectoracula]

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.

[laumars]

> 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.

[badsectoracula]

> 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.

[laumars]

> ..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.

[badsectoracula]

> 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.

Clearly in your message here:

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

...you only refer to storing credentials (ie. passwords) and here:

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

you explicitly refer to "password stores".

Meanwhile from the very beginning, like in here:

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

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:

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

...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.