Who keeps an eye on clipboard access?

https://blog.ovalerio.net/archives/2346

by pndy • 4 years ago

258 144 4 years ago

blog.ovalerio.net

alexvoda• 4 years ago

To what degree does Wayland solve this compared to X?

jchw2• 4 years ago

I believe in Wayland, only foreground applications can access the clipboard. I can’t recall how poorly XWayland fares; I suspect it just bypasses the security boundary. Nonetheless, still useful, especially e.g. for sandboxed apps.

I don’t think clients can, without extensions, watch for who’s snooping the clipboard. However… it probably wouldn’t be difficult to integrate this into the compositor. You could even imagine a Wayland protocol for watching clipboard accesses, or god forbid, a dbus service for doing so.

Arnavion• 4 years ago

I believe in Wayland, only foreground applications can access the clipboard.

To be precise, Wayland does not care who or what accesses the clipboard. Whether or not only foreground applications can access the clipboard is determined by which clients the particular compositor sends wl_data_offer events to.

So the answer to alexvoda's question is: Wayland doesn't solve the problem completely. wl_data_offer events are pushed from the compositor to the client rather than the client asking for a data offer. The compositor cannot know whether the client may want the data offer, so it has to send the event to every client regardless of whether the client ends up needing it or not. For most (if not all) compositors today, "every client" means "clients that are currently focused", so while a background application can't snoop your clipboard, simply focusing such an application would allow it to snoop.

Furthermore, extensions like wlr-data-control are specifically designed for background snooping, since they're intended to be used by clipboard managers. It's again up to the compositor to apply security to this, like only allowing a single specific process to be the data control manager and not arbitrary programs. For wlr-data-control I'm not aware of any compositor that applies such a policy; it would, at the very least, break `wl-paste`.

emersion• 4 years ago

XWayland as a whole is itself a Wayland client. So as long as any X11 window has focus then any other X11 window can steal the clipboard. But once a Wayland window is focused, X11 windows don't have access anymore.

tiku• 4 years ago

I have removed the LinkedIn and Twitter app because they force directed the website to the app, but good to know that it could also see my clipboard and even track it perhaps..

rcthompson• 4 years ago

On recent Android versions you get a pop-up notification whenever an app accesses the clipboard. (I think it doesn't notify for the active app, or maybe it doesn't notify for explicit user-initiated clipboard interactions, I'm not sure exactly what the rules are.) If I saw any app repeatedly accessing the clipboard for no discernible reason, I would definitely uninstall it.

jeroenhd2• 4 years ago

Android killed background clipboard access in an Android update entirely, except for system and vendor applications. I had to root my phone to get clipboard sync working again in KDE connect.

I haven't seen the notification myself, but I'm still on Android 11. From what I can tell for user-installed applications, only the active application and the keyboard get clipboard access, regardless of permissions and capabilities declared in the app manifest.

I get why they did this but I think it's a bad choice not to allow the user to opt into clipboard management. Going back to manually typing TOTP codes was more annoying than rooting my phone.

Hallucinaut• 4 years ago

I have a Pixel 6 and I've noticed an app from some Wi-fi lights with an app called TCP Smart copies my clipboard whenever I open it. I was disturbed by this and definitely didn't do anything special to permit it, so that seems somewhat at odds with what you're saying?

adrianmonk• 4 years ago

More info (from https://developer.android.com/about/versions/12/behavior-cha...):

Clipboard access notifications
On Android 12 and higher, when an app calls getPrimaryClip() to access clip data from a different app for the first time, a toast message notifies the user of this clipboard access.
The text inside the toast message contains the following format: APP pasted from your clipboard.

throwntoday• 4 years ago

iOS/macOS really need to add clipboard to privacy settings. I opened monopoly on iOS and the first thing it did was paste my clipboard to god knows where.

bagels• 4 years ago

Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?

kukx• 4 years ago

It can be useful of you want to use a non standard way to paste stuff, example a right mouse button in putty.

jchw2• 4 years ago

IMO: you have to look at how OSes and window systems were designed and evolved to get a great answer here. Those processes resulted in systems where the OS or compositor or window system itself can’t really know when the user is pasting something or not. It could be changed, but it would have lots of implications globally, from rewriting framework code, to changing JS APIs.

Edge cases would be handled worse, like non-standard paste gestures or VM integration.

kelnos• 4 years ago

Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it.

Sure, there are ways that you could design the system, such as making it so the only way to paste is for the user to hit a key combination, or perhaps click on or touch a UI element that is known to be controlled/hosted/owned by the OS. Then the OS can push the clipboard contents to the foreground application, rather than the application trying to pull it. But then that becomes very limiting, UX-wise. (For example, you wouldn't be able to put a "paste" item in a context menu.)

You could also have a permissions model, where the OS prompts for permission every time an app wants to fetch the clipboard contents (presumably with an "I trust this app" option to get it to stop asking). But that might be considered too intrusive, or possibly just ineffective, as people will often just mash at whatever button is closest to get a modal dialog to go away.

At any rate, we have these copy/paste mechanisms from when people didn't really think about local security in the way we do today. Redesigning things would break a lot of existing applications. It might be worth it, or it might not.

BelleOfTheBall• 4 years ago

Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.

pishpash• 4 years ago

Forget a permissions model. How about an informed notification model, where the OS marks the application with a badge notification whenever it requests a paste? And you can see a history of what it requested?

Generally I find it odd that there is so much hand-wringing over basic transparency. As with companies giving away private data to third parties, before talking about consent, how about a paper trail to start with?

dan-robertson2• 4 years ago

The way it works for webapps is that you are only allowed to read or write the clipboard in the event handler for certain events, but it isn’t really watertight and that sort of mechanism isn’t so feasible outside the web where you don’t have so much control on how programs handle events.

tonyg4• 4 years ago

you wouldn't be able to put a "paste" item in a context menu

I don't know about that. One approach would be for the menu invocation to accept a capability object representing the active context's interpretations of "copy", "paste", "save" etc. (A "user agent" if you will!) The menu would then invoke methods on that object. That way, interactions triggered by the mouse would propagate the appropriate capability. Other uses of the menu would have to synthesise an object of the correct type, which they could do, but they wouldn't be able to forge access to the user's clipboard.

In general, capability style thinking benefits from removing ambient authority such as a global clipboard, replacing it with an object explicitly representing the necessary authority in each context.

Findecanor2• 4 years ago

For example, you wouldn't be able to put a "paste" item in a context menu

Maybe the menu item could be a special window/widget type specific for the "paste" action, controlled by the UI server. An app could be restricted in how many of these it could have and what to display in it.

dolmen4• 4 years ago

"Redesigning things would break a lot of existing applications".

Only a few applications handle triggering of a Paste action by themself. Most just leave the OS/GUI framework/ handle events and only react to a Paste request event. They would not be affected if the OS stops allowing to read the clipboard while a Paste event isn't being processed.

lcnmrn• 4 years ago

Clipboard should be a private and secure enclave (encrypted) in the first place. Only the OS should store and retrieve data from it.

Gigachad• 4 years ago

It’s pretty safe in web browsers. Any app can write to it but the only way to read is if the user hits the paste shortcut.

edave646• 4 years ago

The applications still need to retrieve data for the clipboard to be of any use to anyone. E.g. Editor widgets like to have a paste button. Edit > Paste is a fairly common pattern, too.

Without having the OS in charge of managing the entire UI, it's difficutlt to make that work

tonyg4• 4 years ago

Indeed. Our OS security models will keep being broken until people start taking object capability design seriously ¯\_(ツ)_/¯

rank02• 4 years ago

Is it possible to deny clipboard access to every application and only pass the info through stdin through the explicit ctrl-v or pbpaste/xclip/whatever?

fsflover• 4 years ago

Yes, on Qubes OS, https://qubes-os.org. It's based on VMs for secure and transparent compartmentalization.

rank02• 4 years ago

I am familiar with Qubes, but I'm asking if this specific security control could be used elsewhere.

tlarkworthy• 4 years ago

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

Gare• 4 years ago

Some password management programs (I know for KeePassXC) clear the clipboard automatically after several seconds.

mackatap• 4 years ago

Bitwarden does as well, though it seems more like 20-30 seconds.

SubiculumCode• 4 years ago

This is good to know, but it still doesn't help if there is an application phone app, etc, that monitors the clipboard.

npteljes• 4 years ago

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.

ZeroGravitas• 4 years ago

This is part of the reason I don't set Vim to automatically fill the system clipboard and only do so on demand.

I think a few other geeky apps let you cut and paste internally as a separate thing from the global clipboard, which seems wise as a mitigation.

adrium2• 4 years ago

Does it really come as a surprise that apps are exploiting the clipboard?

TLDR: Drag and drop sensitive stuff. If necessary, copy only part of sensitive information, enter the rest manually.

The amount of usability obstacles in the name of security is getting ridiculous. 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.

Similarly annoying are the cookie questions. In the beginning, I found it interesting and tried to reduce the number of cookies as much as possible - now I just click what ever button brings me to the site fastest (or don't click a button at all, if it is still possible to scroll and see about half of the page on mobile).

Don't you also feel some kind of fatigue?

Now please do not cripple the clipboard the same way. By the way: Qubes OS takes an interesting approach here. Similar to suggestions by some of the commenters. [1]

Don't get me wrong: I am extremely sensible to security - but also to usability. I want to use my daily-driver system conveniently and it should "just work" and I want to trust it fully [2]. I do not just install any trash app, simply because there is one available.

On the desktop:

1. Only applications from the official repos get installed. I may install other open source software occasionally. So yes, the trust lies with the distro.

2. Other software (potentially untrusted or good to be isolated) like banking or tax software or zoom get a proot environment or a new user profile.

3. Most software can be run in the browser anyway and it is actually quite a nice sandboxing tech. Web apps can not simply read the clipboard. [3]

4. Clear cookies on browser exit. I have a whitelist for about two or three sites to keep the state for convenience.

5. Browser extension that manages and fills passwords on request(!). No need to copy-paste around. [4]

6. If I need passwords elsewhere, I use drag and drop. I believe this is extremely convenient and very secure. That works 90% of the time, otherwise, I copy only part of the sensitive information and enter the rest manually.

On mobile:

1. Same goes for app installation: open-source only from F-Droid.

2. Other apps get put in a work profile and disabled when not used. [5] No trash like games and social media.

3. Do not copy paste sensitive information, but use IME apps (keyboard apps that actually "type" passwords). Personally, I like KeePassDX and sometimes use KDE Connect. [6]

Accounts:

1. I own several domains and mobile numbers, all companies that want my info get different data.

2. Fill in bogus information if possible.

I may have gone overboard with this :-D But I don't even care about MFA that much at this point... And it is an interesting experiment to see what company leaks data.

[1] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ [2] Kubuntu fanboy here and Android still on version 8 though because of ROM customization [3] https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/r... [4] https://github.com/adrium/easypass [5] https://f-droid.org/en/packages/net.typeblog.shelter/ [6] https://www.keepassdx.com/ and https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ And I wrote a KeePass plugin to convert the passwords: https://github.com/adrium/KeepassPfpConverter

ummonk2• 4 years ago

"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?

adrium2• 4 years ago

Hmm... Yes, but I am only aware to use it for unlocking the computer...

photon12• 4 years ago

The Qubes clipboard model is one of the reasons I use that OS: https://www.qubes-os.org/doc/how-to-copy-and-paste-text/

alkonaut• 4 years ago

That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same.

I can’t trust all web pages but trusting all my desktop programs is a much easier pill to swallow.

Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without being in focus or sent any input first.

badsectoracula15• 4 years ago

Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access

That would break clipboard managers which are very useful tools to have in various occasions. E.g. in a previous job i worked at, some audio designers used a clipboard manager to quickly fill settings in various tool fields.

Fun fact: most clipboard managers tend to use global shortcut keys for cycling through the recent N copies (or for pasting specifically tagged content, e.g. copy something and mark it to be used for pasting after Shift+Alt+1 is hit, same for Shift+Alt+2 for something else, etc), which is another thing that you'd hear security concerns for :-P

nsgi• 4 years ago

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

kibwen• 4 years ago

That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same.

To be clear for others who may be reading this, this statement isn't a hypothetical, web browsers do prevent web pages from reading the clipboard.

dethos4• 4 years ago

Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without being in focus or sent any input first.

Author here, yes, this is indeed the point of the article. Desktop operating systems could/should have implemented such a feature a long time ago, it is clearly a security "blind spot" at the moment.

IshKebab3• 4 years ago

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.

beermonster• 4 years ago

Is there a Little Snitch/open snitch/Lulu type tool for Clipboard access?

dethos4• 4 years ago

As far as I'm aware, there isn't. And it would be a nice tool to have available, I suspect this could be integrated into existing clipboard managers.

DavideNL• 4 years ago

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

nigwil_• 4 years ago

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 ~ %

CyberShadow10• 4 years ago

Currently writing a clipboard manager[1], I've seen some things as well.

- So far ran into two applications which don't even implement the X11 clipboard specification (ICCCM section 2) correctly - xsel and Emacs (patches submitted).

- By far the worst offense I've seen in clipboard privacy on the Linux desktop is RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines, even when they are not focused, with no indication that it's happening, and with no GUI option to turn it off. This is at odds with the common practice of running untrusted code in virtual machines.

- X11 being network-transparent makes its protocol fairly malleable, so it's not difficult to bolt some privacy on top. hax11[2] has an option to restrict access to the primary selection for configured applications (though, for truly malicious applications, you may find X11's security model generally lacking).

[1] https://news.ycombinator.com/item?id=29808487 [2]: https://github.com/CyberShadow/hax11

thrwawy283• 4 years ago

I've always wanted an application dedicated to managing the clipboard. It would provide security and even offer interchange conversion that existing apps do not implement. For example: Copying HTML in Windows it has an associated mime type that receiving applications can recognize and choose to convert from.

I've always wanted a clipboard/paste manager - with history - like this, that would allow me to copy, manipulate, and paste or share that data to another application.

I don't know how this would look, but even the ability to pop open my paste manager and look at the copied contents, filter it, or split the text, or (silly stuff) convert text to emoji'fied content, or take a screenshot of that (text to bitmap), and create a new entry within the paste manager. For some of my friends it would be awesome to have a hex editor in there.

Perhaps there are 2 focuses: Isolating what is copied from applications until the user chooses to expose it, and the history function. Being able to send it to another app for manipulation and pulling it back is a 2nd responsibility. It would be /suave/ to have this all in the same GUI brought up by the compositor, though.

indentit• 4 years ago

For Windows, there is "ClipboardFusion" by Binary Fortress, which acts as a scriptable clipboard manager, and could tick most of your boxes.

I'm not sure how possible it would be on Windows for a third party app to perform isolation - maybe if it registers a hook for when clipboard content changes which is somehow guaranteed to run first before other applications and any hooks they may have, it could swallow the event and clear the clipboard so other processes can't see it, and then do something similar with paste events maybe?

y4mi• 4 years ago

That does sound great.

While it's not what you're looking for, a lot of people also don't know that windows has a built-in copy paste history if you use windows+v instead of ctrl-v. That's quiet handy too, but a fast cry from what you've proposed there

6equj5• 4 years ago

I don't know how this would look

Probably something like KDE's clipboard? ; p

https://i.imgur.com/zXTLzoO.png

1vuio0pswjnm7• 4 years ago

https://f-droid.org/en/packages/org.dslul.openboard.inputmet...

This replacement keyboard for Android saves clips and allows the user to select and paste them into any application. Most importantly, it allows the user to delete the contents of the clipboard. It also allows the user to "pin" certain clips to be retained for future pasting. Clip storage.

If one needs a further reason to replace the keyboard, consider that the default keyboard on Google phones, Gboard, tries to phone home to Google. A keyboard that expects internet access. Incredible.

Rygian• 4 years ago

RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines

Do you know what's the CVE for that one?

CyberShadow10• 4 years ago

Let's see where this goes:

https://github.com/virt-manager/virt-manager/issues/358

Edit: found this, so maybe Red Hat considers this a feature which is working by design: https://github.com/virt-manager/virt-manager/pull/166

root5• 4 years ago

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

pierrefermat1• 4 years ago

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

octavqq• 4 years ago

hehehe

AshamedCaptain5• 4 years ago

it seems that due to the nature of X11 it is not possible to know which running process owns the window that is accessing the clipboard. A shame.

You definitely can. Search for _NET_WM_PID. Now this being X11, this is again just a convention, and a client could put any information it wants in that property.

While very useful, this raises a lot of security questions.

Really, it doesn't.

If these programs want to share information, they already can. If these programs want to spy on each other's memory contents, they already can. Unless you are running these programs as different users and with different home directories, which is not usual right now in desktop GNU/Linux (but is on Android).

dethos4• 4 years ago

You definitely can. Search for _NET_WM_PID. Now this being X11, this is again just a convention, and a client could put any information it wants in that property.

That was the reason I mentioned that "it is not possible to know", perhaps "for sure" is missing at the end of the sentence.

Really, it doesn't.

As a user (at least in my opinion) it does.

If these programs want to share information, they already can. If these programs want to spy on each other's memory contents, they already can. Unless you are running these programs as different users and with different home directories, which is not usual right now in desktop GNU/Linux (but is on Android).

The point is, when the user copies a piece of information he has a clear target for that information (clipboard is the tool he uses do copy from one window to another), why would all other apps have access to it?

It is the user that wants to share information not the apps.

Even taking account all those capabilities, many pieces of malware rely on detecting and replacing information on the clipboard, that is a clear indication that some sort of isolation is missing here, or at least, and indication regarding that the information was changed/accessed.

AshamedCaptain5• 4 years ago

The point is, when the user copies a piece of information he has a clear target for that information (clipboard is the tool he uses do copy from one window to another), why would all other apps have access to it?

Everything that is run by the user runs in the same context. There is little point in focusing on the clipboard, because any two programs running within the same user can do literally anything to each other. Including spying on each other keystrokes, modifying each other's text widgets contents, and faking whatever text/images they are displaying. The fact that they may alter the clipboard contents is irrelevant when they can literally monitor and inject keystrokes on each other.

This is the security model that we have right now at the desktop. Good luck trying to find a better one that just does not completely break UNIX and turns it into something like Android. One of the benefit of this model is that you (the user) have practically unlimited freedom in hooking the system in ways that nobody expects (e.g. a clipboard access detector), but then so does anybody else you decide to trust (by running their program in the same context).

CyberShadow10• 4 years ago

If these programs want to spy on each other's memory contents, they already can.

No, they cannot. As an unprivileged process, you cannot access other processes' memory, with major distributions' default settings, even if the two processes share the same UID. The only way to achieve that would be to modify some execution path (e.g. .bashrc) to launch an evil wrapper which runs the target process in a way that allows reading its memory.

AshamedCaptain5• 4 years ago

Which distributions and which settings are you talking about?

If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb). And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it).

And as for the second method, that's why I said same home directory. But there is a gazillion of ways. You can even meddle in practically all IPC done by any two processes of the same UID, e.g. attach to sysv or posix shm.

abaines• 4 years ago

With most installations of X11 / Xlib, there is also an extension library: libXFixes. With this, it is possible to receive an event whenever the clipboard (or any other selection) changes (even if our program is not the owner). [0]

I used this in the past when porting a Windows text editor to Linux that needed to know when the clipboard had changed.

In the C bindings, it corresponds to XFixesSetSelectionOwnerNotifyMask / XFixesSelectionNotifyEvent. There is also a SelectionNotify event in the core X11 protocol, but I'm pretty sure it is different (occurs in response to XConvertSelection - asking for the clipboard contents). Though it has been some time since I wrote the code I'm looking at.

[0] https://www.x.org/releases/current/doc/fixesproto/fixesproto... (6. Selection Tracking)

CyberShadow10• 4 years ago

I think the goal here is to be notified when an application accesses the clipboard, not modifies it. You need to be the owner to do that (excluding some system-wide hack like patching the X server or MITM-ing all X11 connections).

c0l02• 4 years ago

I think Linux dynamic user probes would lend themselves quite well for something like this. Fooling around with bpftrace for a few minutes yielded this one-liner, which catches all the conscious X11 selection accesses (and a few unconscious ones, too :)) I provoked on my desktop during a few minutes of testing:

    sudo bpftrace -e 'uprobe:/usr/lib/libX11.so:XGetSelectionOwner{time("%H:%M:%S ");printf("%-6d\n", pid);}'

I am not familiar with Xlib/X11 at all, so I am not sure which library functions one would be most interested in to explore this much further.

Edit: Replaced `XSetSelectionOwner` with `XGetSelectionOwner` in bpftrace invocation.

CyberShadow10• 4 years ago

I am not familiar with bpftrace (though that does look extremely potent), but XSetSelectionOwner is called when an application wants to make data available via the clipboard, not access it. Also not sure if that would also catch stuff with Xlib, and I guess it won't if it's statically linked (this is why I pivoted hax11 from hooking library calls to MITM-ing the connection).

c0l02• 4 years ago

My bad, I actually had the "production" trace command set to look for `XGetSelectionOwner`, but mis-pasted into my comment ;) Will that fare any better? It did make a few more PIDs/culprits end up in the trace output for me after all.

You are correct that "bringing your own function"/shared object will break that particular bpftrace script, but I would assume one could find a way to set up a probe in the X server, where all clients messing with clipboard state via some kind of IPC have to pass thru? (Again, I can only wildly speculate how X11 works under the hood - kinda shameful that I never bothered to look over all these years :-S )

backtoyoujim• 4 years ago

Then what watches the clipboard watcher ?

dolmen4• 4 years ago

The user.

anderspitman• 4 years ago

I've been thinking it would be fun to make a self-hosted web clipboard that lets you paste text/files into a simple web page, and have them available on all your devices. Sort of like cl1p.net but e2ee and it would maintain history.

You wouldn't need an account because your password could be hashed to yield a unique URL.

Only reason I haven't hacked it together already is because I don't trust myself to get the crypto right yet.

Anyone aware of something like this already existing?

Damogran6• 4 years ago

I had thought about something similar, only with publishable subscriuptions so N people could share the same clipboard. Only I wanted the opposite: It would be ephemeral, only as long as you subscribed to the ‘feed’ would you see what was there, there would be no history, and pragmatically, no long term retention in the cloud…mostly as a cost savings measure.

I got so far as thinking you’d have two guids: One to subscribe to, and the other to revoke the feed.

It never got past the thought stage…and I made a logo and registered a URL that I’ve since let expire as the coding took longer than my attention span.

tomerv• 4 years ago

You're just a few steps away from reinventing Twitter!

juglans• 4 years ago

Bit Warden password manager app for Linux desktop has an option to clear the clipboard:

file -> settings [options]'clear clipboard': dropdown select range from 10 seconds to 5 mins or never.

Set & forget.

opan• 4 years ago

KeePassXC does this as well. Even if just copying the username.

phkahler• 4 years ago

It would make sense to sniff clipbaod paste commands and offer the active app a one time read access for each user provided interaction.

Not sure about the value of requiring the same for writes, but it wouldn't hurt.

Any time an unauthorized read is attempted the user could be informed.

Not sure where this would get plumbed in. Needs support at the toolkit level (menu->edit->paste) and some higher level outside apps.

The idea is to obey the users implicit concent and flag everything else.

jonnypotty• 4 years ago

I used to support a terminal services/citrix environment and we had repeated instances of people trying to copy and paste data and getting other peoples data. Never got anywhere investigating and boss refused to go to Microsoft. I'd forgotten about it till I read this.

Jenda_• 4 years ago

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

Who keeps an eye on clipboard access?

Related Stories