Earlier quoted context omitted.
On my browser (Firefox 96), the paste command seems to just return false and do nothing.
Are you running it as part of a click handler?
No, I was trying it on the console, without any context.
Who keeps an eye on clipboard access?
121–130 of 147 posts
Re: Who keeps an eye on clipboard access?
#122Related tool for macOS: https://langui.net/clear-clipboard/ Clear Clipboard allows you to clear the clipboard content manually or automatically, preventing your clipboard data from being peeped while you are absent. You can chose to clear the clipboard content every few seconds and enable clearing clipboard on computer sleep / display sleep / screen lock to maximize protection of your sensitive clipboard data.
Could use Automator with AppleScript:
x@Mac-mini-M1 ~ % cat ClearClipboard.scpt
on run
tell application "System Events" to set the clipboard to ""
end run
x@Mac-mini-M1 ~ %Re: Who keeps an eye on clipboard access?
#123Earlier quoted context omitted.
"For example, when I got a new company mac, I had to enter my keychain access password and grant access to folders countless times - and I still have to do that after one week of using it occasionally." Did you not setup Touch ID?
Hmm... Yes, but I am only aware to use it for unlocking the computer...
Try using it the next time a password prompt comes up.
Re: Who keeps an eye on clipboard access?
#124Earlier quoted context omitted.
If you do that then why can't the program invoke methods on that object whenever it wants to?
Good question. You only pass it with an interaction event. (And you revoke the capability once the interaction is over.) Not perfect: stops background pasting without interaction tho. To do better, the only way I can think of right now is having paste only triggerable by a secure context (e.g. keyboard shortcut, as above). Any mechanism by which the user can declare "I intend to paste" in so many words without the ap…
Sure, if the OS offers an "add a cut/copy/paste menu option here" as part of their native UI library (if they offer one) then that could work, and/or saying "I delegate cursor focus, cmd-x, cmd-c and cmd-v to the OS to control for clipboard access".
I just didn't understand how the specific mechanism you were describing would help.
Re: Who keeps an eye on clipboard access?
#125At least, I have a script that runs every minute, and if the clipboard contents has not changed, it flushes it. This really helps in preventing accidental paste of sensitive stuff that remained in the clipboard.
I also have script that strips newlines (so I can relatively safely paste into terminal without executing anything) and formatting (so I can paste into WYSIWYG editors). All of this is done by simple xclip -out | ... | xclip -in.
There was a bug in stardict: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960
- if you selected something (i.e., copied to clipboard), it tried to look it up in a dictionary and display a translation (by default, just after startup)
- online dictionaries, including one available only over HTTP, were enabled by default
- so if you used a password manager that copies passwords into clipboard, they were immediately sent in an unencrypted request for the whole world to see
We desperately need an application firewall (something like OpenSnitch, but that's so difficult to configure correctly) and basic app isolation (like QubesOS, but that's heavy and pain to use) for Linux. It's a shame that most other OSes, despite having other problems, implement this correctly.
Re: Who keeps an eye on clipboard access?
#126Earlier quoted context omitted.
Are you running it as part of a click handler?
No, I was trying it on the console, without any context.
As I said, it needs to be as a direct reaction to user interaction. Though from the other comments, it seems my knowledge here is outdated anyways
Re: Who keeps an eye on clipboard access?
#127Earlier quoted context omitted.
Not really though. It makes sense for mobile OSes because they have proper isolation of apps, but desktop OSes don't have that. Apps can pretty much do anything. What's the point of copy notification if apps can just read all your emails and steal all your files anyway. Android and iOS both have this feature already. That's the best we can do for now.
Desktop OSes all have some form of optional sandboxing now, so it makes sense to keep chipping away at the edges of the attack surface.
Do people use them though? Both Mac and Windows have pretty much tied app sandboxing to 30% app store fees, which means the proposition is "rewrite your app to use incomplete APIs and then you can put it in our store where we'll take a big cut!"
Not very appealing. It only works on mobile because there wasn't an existing industry used to 2% fees and unrestricted APIs.
Unsurprisingly Microsoft has abandoned app store fees and mandatory sandboxing so their app store has any chance of being used. Not sure about Apple.
Re: Who keeps an eye on clipboard access?
#128Earlier quoted context omitted.
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…
> 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 -…
> 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.
Re: Who keeps an eye on clipboard access?
#129Earlier quoted context omitted.
Desktop OSes all have some form of optional sandboxing now, so it makes sense to keep chipping away at the edges of the attack surface.
Do people use them though? Both Mac and Windows have pretty much tied app sandboxing to 30% app store fees, which means the proposition is "rewrite your app to use incomplete APIs and then you can put it in our store where we'll take a big cut!" Not very appealing. It only works on mobile because there wasn't an existing industry used to 2% fees and unrestricted APIs. Unsurprisingly Microsoft has abandoned app store…
Can't apps use sandboxing with Apple's notary feature without needing to distro on the app store? and the incentive is the lack of a scary warning?
Re: Who keeps an eye on clipboard access?
#130Earlier quoted context omitted.
> 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 -…
> 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…
> ..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.