Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Who keeps an eye on clipboard access?

blog.ovalerio.net

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Who keeps an eye on clipboard access?

#51

Post by badsectoracula »

laumars wrote: post #46
badsectoracula wrote: post #42

Earlier quoted context omitted.

> 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 s…

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

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.

Re: Who keeps an eye on clipboard access?

#53

Post by npteljes »

tlarkworthy wrote: post #10

I have taken to copying a benign string after using a sensitive password and I minimize switching tabs during transport of said password.

That's a good practice. KeePass 2, KeePassX and KeePassXC, and KeePassDX on Android do this by default as well. It's even better to use the Auto-Type feature of these software, because then the password never gets on the clipboard in the first place.

Re: Who keeps an eye on clipboard access?

#54

Post by pierrefermat1 »

root5 wrote: post #52

As iOS and macOS share their clipboard over BLE, one can abuse this feature for various things like smart home automation. https://twitter.com/m33x/status/1489236070151737351

If I read the tweets correctly this is only capable of capturing the event happening and not the content? I don't see this too much of a privacy issue

Re: Who keeps an eye on clipboard access?

#55

Post by summm »

badsectoracula wrote: post #42
nsgi wrote: post #39

Earlier quoted context omitted.

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

> 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 s…

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.

Re: Who keeps an eye on clipboard access?

#57

Post by badsectoracula »

bryanrasmussen wrote: post #49
badsectoracula wrote: post #47

Earlier quoted context omitted.

> Suppose you were running a capability-secure operation system, or that your mail system was written in a capability-secure programming language. In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your addres…

>That sounds like a usability nightmare. sure but any email system should not have to request the capabilities to do any of these things, so basically if a message came in and it started requesting these capabilities - it would only be malicious messages that would do it. This is following the principle of least access/authority http://wiki.erights.org/wiki/POLA

An email client certainly needs the capabilities mentioned there. The ILOVEYOU virus (which is what the page refers to) was an executable (a VBS script but any executable could do the same thing) that asked Outlook Express for the address book and use it to send mail with itself as an attachment. The issue with it was that Outlook Express was too happy to run programs attached to mail (also that Windows hide file extensions by default and... people tend to respond to affection - at the end of the day you can't solve social issues with technical solutions) without even a warning (though a warning would be most likely ignored anyway due to the social aspect of the message - which is also what would happen with the warning in the dialog mentioned in the linked page too).

And at some point you'll have to request these capabilities and the user will have to grant them. So the user, as is seen with mobile permissions nowadays that serve more to make developers feel good about providing security and pat each other on the back about how thoughtful they are (meanwhile there is a ton of malware on Android phones), will simply grant the permissions because they want to run the application - the reason they went into obtaining it in the first place.

You can see the issue clearly in that infamous video from Linus Tech Tips where Linus tried to install Steam and end up breaking his desktop despite lots of warnings from the system - he had a goal (to run the program) and in the pursuit of that goal he ignored pretty much every warning the OS gave him, including even forcing him to type "yes i know what i am doing".

These solutions are pointless and only help to make the programmers who implement feel good that they implemented them. Like the solution to problem above where now you have to make a special file in the root folder to do that, as if someone who ignores everything in the pursuit of a goal to type "yes i know what i am going" aren't going to type "sudo touch /.magic_file" (that they copied from a forum post).

The only way to stop people from doing something it to make it technically impossible to do it. But at that point you are starting to make tasks impossible to achieve and people use computers to do things and anything that goes towards that is missing the forest (people using computers to do things) for the tree (some things can be unsafe so let's not anyone do it).

Re: Who keeps an eye on clipboard access?

#58

Post by laumars »

badsectoracula wrote: post #51
laumars wrote: post #46

Earlier quoted context omitted.

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

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…

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

Re: Who keeps an eye on clipboard access?

#59

Post by badsectoracula »

summm wrote: post #55
badsectoracula wrote: post #42

Earlier quoted context omitted.

> 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 s…

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 th…

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.

Re: Who keeps an eye on clipboard access?

#60

Post by badsectoracula »

laumars wrote: post #58
badsectoracula wrote: post #51

Earlier quoted context omitted.

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…

> 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 (…

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

Post reply on HN