[nsgi]

Sure, but that should really be a permission you have to grant explicitly.

For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts

[badsectoracula]

> Sure, but that should really be a permission you have to grant explicitly.

That could work but still feels dodgy since if you can grant that permission to a clipboard manager, you can also grant it to something like a TikTok client or an Adobe DRM reader or whatever else program you want to use (ie. the reason you are using your computer in the first place) but also might want to snoop for your data.

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 with explicit permissions for reading it, notifications for writing to it and whatever else 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.

Sure some people will still use Copy but some people will also stick post-it notes with their passwords on their monitors and give thousands of dollars to Nigerian princes - you shouldn't to punish everyone for the ignorance of a few.

> For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts

This only works if all applications are using the same framework and toolkit and target the same OS. Meanwhile notice how even when you limit yourself to applications targeting Windows alone there are tons of different frameworks - let alone cross platform applications that tend to use a lowest common denominator approach.

IMO if you want to get more secure functionality, you need to do it in a way that works alongside existing practice - hence containers and sandboxing for untrusted applications working alongside trusted applications that can do what they want. Unless you start everything from scratch on a brand new computing approach (like mobiles did and even then it barely works and despite people treating mobiles almost like consumables), trying to force a top-down approach to security is doomed to fail.

[laumars]

> 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 with explicit permissions for reading it, notifications for writing to it and whatever else you want.

If we are going to break standard APIs then why not do away with the clipboard for secrets entirely and have a global secrets store that applications can pull credentials from directly and securely instead of passing secrets via a clear text protocol.

This is how Linux and macOS work (albeit I wish 3rd party stores could natively integrate with them). This is how cloud computing works too (eg AWS Secrets Manager). Using a clipboard for copying secrets is completely the wrong approach regardless of how much you over-engineer your clipboard manager.

[badsectoracula]

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.

[laumars]

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

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

[pmontra]

Of course if an app asks for some very dangerous permissions somebody will grant them to it even if they don't belong to the app's advertised functionality.

Naming and description could help a little: Full access to copy and paste (maybe somebody doesn't know what clipboard means), it allows this app to access everything is selected and copied including passwords, private data, etc. Only keyboards and clipboard managers should get this permission.

[badsectoracula]

> Naming and description could help a little: Full access to copy and paste (maybe somebody doesn't know what clipboard means), it allows this app to access everything is selected and copied including passwords, private data, etc. Only keyboards and clipboard managers should get this permission.

I don't think the problem of users not reading the text in warning messages can be solved with having them read even more text.

Actually this is an old problem, people do not read message boxes, popups, warnings, etc:

http://www.zuschlogin.com/?p=53

[dolmen]

The permission should be just "allow to read clipboard when the app doesn't have focus". Only clipboard managers should need this to read clipboard data in the background. Any other read of the clipboard should have been triggered by a user action in the app that requires the read, and that's what the OS should enforce.

[summm]

Why does it feel dodgy? When I want to give Adobe DRM or TikTok those permissions, I should be able to. They just shouldn't have the option to force me, or else stop running. Do you really condone the trendy dumbing down to an user-hostile walled garden? It's even Windows nowadays: They make it super hard to change file associations, change it back to Edge on every update, and even don't let other programs support the user. All under the pretext of "protect the user from bad applications", but really misuse it to drive usage of their own apps. The same will happen with that clipboard function.

[badsectoracula]

It feels dodgy because they give a false sense of security, i wrote about it in another reply: https://news.ycombinator.com/item?id=30220373

> Do you really condone the trendy dumbing down to an user-hostile walled garden?

The complete opposite in fact, i dislike the increasing usability nightmare that modern desktop OSes creep in in the name of protecting users who are going to do their thing regardless unless the relevant functionality is completely removed - at which point someone should stop, take a few steps back and think why people use computers in the first place.