I used to use TickTick as my to-do list. I moved away from it because it read my clipboard constantly. Likely, it wasn't nefarious at all, but there was no way for me to audit it... The app is closed source, and the permission is granted regardless.
I'm so glad GrapheneOS supports this. P.S. If you're on GrapheneOS, this isn't enabled by default, but it is a global toggle - Please enable it.
blfr 13 hours ago [-]
Great title, upvoted on its strength alone, just delightful, but a phone clipboard really isn't the place to store secrets. Sure, one-time codes, but not permanent secrets.
Instead of trying to turn the clipboard into some citadel, it would be way more beneficial to security and UX to have more reliable password manager fill-ins.
seszett 1 days ago [-]
I've always been irritated by the lack of control on whether apps can inspect the clipboard or not.
The bpost app (Belgian national post) immediately reads the clipboard when it gets opened and I hate this behaviour with a passion. While on the other hand it throws a fit if it ever detects an unlocked bootloader, root access, "suspicious" apps or whatever.
I ended up confining it to an outdated phone with a stock OS along with the bank and identity apps that I cannot avoid. I digress, but the original cause of my irritation was indeed lack of control on my clipboard that ia had noticed thanks to that small notification.
Gander5739 1 days ago [-]
For what it's worth, grapheneos allows you to control this permission.
lolpython 1 days ago [-]
iOS too
StilesCrisis 1 days ago [-]
Why would the Belgian post hack your phone?!? Of all the things to be suspicious of, that one's low on my list.
Rebelgecko 18 hours ago [-]
Yes of course, we can always trust businesses known for making shady deals with national governments
vntok 1 days ago [-]
You never know, Sezsett might be a big fry.
prism56 1 days ago [-]
Yeah agreed. The Toast notification is terrible UX.
Thanks for letting me know an app already read my address/CC number/privatemessage/image.
LoganDark 23 hours ago [-]
We're toasting to inform you that your system clipboard suffered an unfortunate data breach. Don't worry, we've discovered no evidence that any other systems were accessed... We're contacting you now so that we can say that, and we won't provide any update if we discover otherwise later.
Obscurity4340 8 hours ago [-]
Capt. Hindsight saves another Day!
chinhodado 1 days ago [-]
A long time ago I wrote a dictionary app for my own use, which would show word definition upon the word being copied into the clipboard (e.g. from an e-book reader app). The dictionary app would run in the background and only show the pop up on clipboard event.
Then around Android 10 they tightened security and decided background apps can no longer receive clipboard event. Which makes sense from a security standpoint, but it totally broke my dictionary app. I just wish they're a way as a developer to get around it with my own app.
anabab 1 days ago [-]
Presumably apps can plug in entries in the system wide context menu? E.g. I have an Anki menu item (not talking about app selection screen to share content!) when selecting text in Firefox
david_allison 24 hours ago [-]
Yep, via ACTION_PROCESS_TEXT - this also allows you to show a UI and modify/replace the selected text.
PS: the menu can be disabled in the "General" settings of AnkiDroid... I need to get around to better onboarding for it.
chinhodado 19 hours ago [-]
That doesn't work if the reading app has its own custom context menu (e.g. Google Play Books app)
Permik 1 days ago [-]
I'm not sure if this was the documentation defined workaround, but they added the ACTION_PROCESS_TEXT intent, which could basically give near identical UX.
vintagedave 1 days ago [-]
I don’t use Android so I’m not sure what I’m seeing in the embedded video. Is it that there should be a notification at the top of the screen but there isn’t? I thought the article implied it used two different notifications that hide the system one but I see none at all.
deathanatos 1 days ago [-]
I do use Android, and I have no idea what the article is talking about, and AFAIK, I have never seen a toast when the clipboard is accessed.
Even if I say something like "maybe the on-screen keyboard is exempt?" and say, open Firefox, and use the in-Firefox option of "Fill link from clipboard" instead of long-press & paste … no toasts?
(And yes, I'm after Android 12, this phone is new.)
tfvlrue 21 hours ago [-]
Same here, also confused. I've only ever had Android phones (currently on Android 16) and I don't know what it means either. Pasting from the clipboard using a keyboard, an application action, or a context menu doesn't show a notification or toast. I tested it just now. The only system-level thing I see is a "Copied" toast, which is visible in the article's video.
Is this specific to particular Android versions or vendors? Curious if anyone can elaborate what we're supposed to see here.
edit: I will note that copying a password from a password manager showed it masked with asterisks in the keyboard's paste button.
Sophira 7 hours ago [-]
On my (admittedly GrapheneOS) phone, it's a setting at Settings->Privacy->Show clipboard access.
Sophira 7 hours ago [-]
On my (admittedly GrapheneOS) phone, it's a setting at Settings->Privacy->Show clipboard access.
xandrius 1 days ago [-]
Really? Never seen it? I guess nothing reads your clipboard but generally you should get a notification when an application accesses it.
ycombinatrix 17 hours ago [-]
BMW app reads your clipboard every time you open the app.
swapsCAPS 18 hours ago [-]
Heh, I abuse this for my Continuity copy-paste bodge. Whenever I switch to Android I miss the cross-device copy-paste from the Apple ecosystem. I think pre Android 10 it was even be possible to access the clipboard from a Service, so an app didn’t even have to be in focus...
Code if you’re interested:
https://github.com/swapsCAPS/sshnip
paol 14 hours ago [-]
The KDE Connect app does continuity-style clipboard sharing. Or it did until Google broke it in Android 10.
The work-around the devs found is pretty good - there is a "send clipboard" action you can add directly to the notifications panel - but it's not as nice as it just working.
streetfighter64 1 days ago [-]
I think allowing any program to read the clipboard at all is a huge mistake. The way it should work is that it's entirely safeguarded by the OS, and the only time an app can see the contents is when it receives them in a Ctrl+V event initiated by the user. This is the way most users, even non-technical, expect it to work, I'm pretty sure.
layer8 1 days ago [-]
There are significant drawbacks with that: Many applications offer different paste actions via menu entries and/or different shortcuts, and sometimes via macros. (I use such non-default pasting all the time.) So there would have to be a mechanism to manage the ways an application is allowed to perform pasting, and to have the user selectively permit or forbid the various ways.
Additionally, the clipboard is often used to copy items within the same application, a mechanism which again can be involved in a multitude of application commands; or else the user must be burdened with having to distinguish between an application-level and the system-level clipboard. This can be partially solved by always allowing pasting of content copied from the same OS process, but multi-process applications would still face hurdles.
Another variation of that is scripting. I have various scripts and CLI aliases that take the current clipboard contents and do something with it.
While the clipboard can be made more secure than it traditionally is, these security measures come with the usual trade-off of making things more annoying for the user.
potato-peeler 17 hours ago [-]
You have entirely misunderstood/misread the comment.
streetfighter64 said “ event initiated by the user.”
Copy/paste can be initiated multiple ways, including through many entries. That does not matter. What matters is , the application has zero knowledge on what is on the clipboard. It can’t read/modify/delete. It can only allow the user to trigger an action, and the result of that action is transparent to the user.
I haven’t misunderstood. For the functions I described, the application has to trigger its access to the contents of the clipboard after the user has invoked an application command that involves access to that contents (among other things the command will do). The OS can’t know which application commands make it transparent to the user that the command will access that contents. And you don’t want to burden the user with having to confirm that the command that he just invoked is permitted to access the clipboard contents. Or maybe you do want that, but then it means a worse user experience.
hyperhello 7 hours ago [-]
If you mean the result is hidden from the application, it’s almost impossible in practice. There are tiny things like not reporting the color of visited links in a browser that are possible, but generally apps need control and visibility over the data they’re processing to work.
silon42 7 hours ago [-]
Not just read, controlling write can also be a problem.
For example if you expect to copy something from an app, the app might ignore the operation, making you then paste somewhere the previous content which might be something sensitive.
(copying/pasting from password managers, etc should be once-only operation, but it's not always like that).
eddythompson80 17 hours ago [-]
On desktop, how do you send that signal when the paste action is a click in the app (like a right click -> paste or a menu -> paste)? It seems you would have to make paste only keyboard driven or require applications to use some form of platform provided component, like UAC for example, that the app can use to request access to the clipboard.
It's easier in iOS and Android where the input can always be controlled through the keyboard and there is mainly 1 or 2 apps in the foreground only so only those apps can request the clipboard like iOS does it.
streetfighter64 15 hours ago [-]
Right click -> paste just triggers a paste event. Menu -> paste just triggers a paste event. The key is that apps can just present the option, not initiate it silently in the background.
Consider how the file picker works. If you press a button in the app, then a file picker is opened, but the app gets no access to anything until you select a file to give it. Clearly, this is way better than giving the app read access to your whole HDD.
Though, that's the way everything used to work previously, and a lot of apps still do that, but, only after the user has granted them full file system reading. So if an app is very specialized, perhaps it could be granted "full clipboard access", though I at least can't think of any app I'd give that.
eddythompson80 12 hours ago [-]
The application is drawing its own context menu though. Like the application itself would be triggering the paste event, what is stopping the application from triggering it whenever?
On desktop the file picker is just a helper library. It doesn’t provide any isolation. That was my question, desktop OSs (windows, Linux) don’t have that security model. Web apps have a different sandboxing where the file picker works that way, but that’s not just a given.
There is one OS that does file permission more correctly, and that's OSX / Mac. For sandboxed apps at least. Windows and linux are lagging behind in that regard.
At least in my opinion, the way it's done on the web and on phones, is the correct model, and the only reason desktop OSes does it differently is legacy.
eddythompson80 7 hours ago [-]
There are options for both Linux and Windows to work that way. You can get flatpaks or snaps on Linux to do that. Windows has the same thing too though I forgot if it's App-V or AppContainer or VXD or whatever they call it. There is no reason Microsoft couldn't release a Windows version that can only run apps in that mode. Pretty sure there will be a major backlash for it though. Same with Linux.
Akronymus 15 hours ago [-]
how do you differentiate between something allowing you to click paste and something that just tells the os you did so? You could make ANY ui interaction perform a paste.
CapitalistCartr 11 hours ago [-]
[flagged]
ryandrake 1 days ago [-]
I feel like the clipboard is something that is on computers today only because it was invented back when dinosaurs roamed the earth, and we can't get rid of it as a concept because it's so ingrained in computing.
If we never had the clipboard (on any computer, not just Android) and it was suddenly invented today, it would never pass any major company's privacy or security review. Here we have something that allows the user to share any data instantly with any process that happens to be listening, including sensitive things like credentials, personal information, the works. It's a security nightmare! In today's paranoid times, no OS would say yes to a new feature like this, but we keep it because it's legacy and it can't be gotten rid of at this point.
simonra 1 days ago [-]
It works moderately well in securing against a program going rogue and trying to prevent the user from moving the data on their device to another program serving them better. (Or underrated but important, making it less painful to enter and re-enter information in say a dark pattern subscription cancellation form.) Unfortunately it's easily defeated as a security mechanism, but it's still way better than nothing.
bluebarbet 13 hours ago [-]
Exactly. The clipboard is interoperability 1.0. It's what makes free computing possible in an imperfect world. Any superseding system that did away with the clipboard would need to be universally supported on day one, which seems unlikely.
afzalive 1 days ago [-]
One simple solution is just to gate the programmatic access by confirming with the user when the app wants to read the clipboard.
hbn 1 days ago [-]
iOS does this
You get an "Allow paste from <app>?" pop-up. Possibly only the first time you past from one app to another? Or maybe it resets after a while. I don't know the details.
Rohansi 23 hours ago [-]
You need give permission to websites too. It's weird they haven't transitioned over to requiring permission on Android yet.
forgotusername6 1 days ago [-]
The last few times in opened the eBay app on android my phone helpfully told me that the app had pasted from my clipboard... No idea what eBay was doing with that but it's a bit late if I had anything sensitive on there
david422 1 days ago [-]
What would you do instead?
vntok 1 days ago [-]
On PC, switching to QubesOS is a good start.
1 days ago [-]
dzaima 1 days ago [-]
Could make a copypasta out of that (ha, ha.).
But like that genuinely applies to a quite large amount of things. Screenshots, screen recordings, actual regular physical cameras, unencrypted physical cables, publically-usable GPS, microphones, etc. (these are even reasonably-realistic - Wayland & phones have restrictions for screen(shots| recording), backslash on cameraful glasses, DRM, criticism of airtags, leaking typed text through the typing sounds)
Could even go broader and count in people being non-anonymous online, and people being anonymous online, as both being bad for security; were the world to have settled on one, the other would be utterly crazy.
Giving semi-arbitrary anything to LLMs should absolutely very-trivially count in this too, except that for whatever reason it's very often just not? Clipboards would get a pass just fine.
dsp_person 1 days ago [-]
On wayland it is difficult to effectively restrict those things. You must create a security context socket and run your app in a sandbox where nothing leaks, no dbus, etc.
On kde plasma right now with all that, wl-paste still sees the clipboard at any time from an unfocused window by creating a temporary invisible xdg_toplevel window that steals focus and grabs the clipboard.
I think we need something similar to xdg-dbus-proxy to control what messages can pass over the socket.
pluralmonad 1 days ago [-]
Your comment is bordlerine absurd given the utility of such a thing as copy and paste. If it is satire, then you got me.
nottorp 14 hours ago [-]
I suppose the OP never exchanges information with other people... or relies on those "share" buttons.
1 days ago [-]
krapp 1 days ago [-]
Today's paranoid times?
The current status quo for software architecture is giving a swarm of LLM agents root and full access to user data and letting them run amok, unsupervised, connected to a proprietary remote black box service either being monitored by Palantir or the CCP. What is this "paranoia" you speak of?
aboardRat4 1 days ago [-]
All programs must be open source and distributed as source.
Everything else is cargo cult security.
saagarjha 14 hours ago [-]
So is that
Rendered at 00:24:55 GMT+0000 (Coordinated Universal Time) with Vercel.
I'm so glad GrapheneOS supports this. P.S. If you're on GrapheneOS, this isn't enabled by default, but it is a global toggle - Please enable it.
Instead of trying to turn the clipboard into some citadel, it would be way more beneficial to security and UX to have more reliable password manager fill-ins.
The bpost app (Belgian national post) immediately reads the clipboard when it gets opened and I hate this behaviour with a passion. While on the other hand it throws a fit if it ever detects an unlocked bootloader, root access, "suspicious" apps or whatever.
I ended up confining it to an outdated phone with a stock OS along with the bank and identity apps that I cannot avoid. I digress, but the original cause of my irritation was indeed lack of control on my clipboard that ia had noticed thanks to that small notification.
Then around Android 10 they tightened security and decided background apps can no longer receive clipboard event. Which makes sense from a security standpoint, but it totally broke my dictionary app. I just wish they're a way as a developer to get around it with my own app.
Source: I wrote that AnkiDroid code ~6 years ago.
https://developer.android.com/reference/android/content/Inte...
PS: the menu can be disabled in the "General" settings of AnkiDroid... I need to get around to better onboarding for it.
Even if I say something like "maybe the on-screen keyboard is exempt?" and say, open Firefox, and use the in-Firefox option of "Fill link from clipboard" instead of long-press & paste … no toasts?
(And yes, I'm after Android 12, this phone is new.)
Is this specific to particular Android versions or vendors? Curious if anyone can elaborate what we're supposed to see here.
edit: I will note that copying a password from a password manager showed it masked with asterisks in the keyboard's paste button.
The work-around the devs found is pretty good - there is a "send clipboard" action you can add directly to the notifications panel - but it's not as nice as it just working.
Additionally, the clipboard is often used to copy items within the same application, a mechanism which again can be involved in a multitude of application commands; or else the user must be burdened with having to distinguish between an application-level and the system-level clipboard. This can be partially solved by always allowing pasting of content copied from the same OS process, but multi-process applications would still face hurdles.
Another variation of that is scripting. I have various scripts and CLI aliases that take the current clipboard contents and do something with it.
While the clipboard can be made more secure than it traditionally is, these security measures come with the usual trade-off of making things more annoying for the user.
streetfighter64 said “ event initiated by the user.”
Copy/paste can be initiated multiple ways, including through many entries. That does not matter. What matters is , the application has zero knowledge on what is on the clipboard. It can’t read/modify/delete. It can only allow the user to trigger an action, and the result of that action is transparent to the user.
Applications shouldn’t have access to contents inside the clipboard, otherwise you get in situations like this - https://cybersecuritynews.com/fake-captcha/
For example if you expect to copy something from an app, the app might ignore the operation, making you then paste somewhere the previous content which might be something sensitive.
(copying/pasting from password managers, etc should be once-only operation, but it's not always like that).
It's easier in iOS and Android where the input can always be controlled through the keyboard and there is mainly 1 or 2 apps in the foreground only so only those apps can request the clipboard like iOS does it.
Consider how the file picker works. If you press a button in the app, then a file picker is opened, but the app gets no access to anything until you select a file to give it. Clearly, this is way better than giving the app read access to your whole HDD.
Though, that's the way everything used to work previously, and a lot of apps still do that, but, only after the user has granted them full file system reading. So if an app is very specialized, perhaps it could be granted "full clipboard access", though I at least can't think of any app I'd give that.
On desktop the file picker is just a helper library. It doesn’t provide any isolation. That was my question, desktop OSs (windows, Linux) don’t have that security model. Web apps have a different sandboxing where the file picker works that way, but that’s not just a given.
There is one OS that does file permission more correctly, and that's OSX / Mac. For sandboxed apps at least. Windows and linux are lagging behind in that regard.
At least in my opinion, the way it's done on the web and on phones, is the correct model, and the only reason desktop OSes does it differently is legacy.
If we never had the clipboard (on any computer, not just Android) and it was suddenly invented today, it would never pass any major company's privacy or security review. Here we have something that allows the user to share any data instantly with any process that happens to be listening, including sensitive things like credentials, personal information, the works. It's a security nightmare! In today's paranoid times, no OS would say yes to a new feature like this, but we keep it because it's legacy and it can't be gotten rid of at this point.
You get an "Allow paste from <app>?" pop-up. Possibly only the first time you past from one app to another? Or maybe it resets after a while. I don't know the details.
But like that genuinely applies to a quite large amount of things. Screenshots, screen recordings, actual regular physical cameras, unencrypted physical cables, publically-usable GPS, microphones, etc. (these are even reasonably-realistic - Wayland & phones have restrictions for screen(shots| recording), backslash on cameraful glasses, DRM, criticism of airtags, leaking typed text through the typing sounds)
Could even go broader and count in people being non-anonymous online, and people being anonymous online, as both being bad for security; were the world to have settled on one, the other would be utterly crazy.
Giving semi-arbitrary anything to LLMs should absolutely very-trivially count in this too, except that for whatever reason it's very often just not? Clipboards would get a pass just fine.
On kde plasma right now with all that, wl-paste still sees the clipboard at any time from an unfocused window by creating a temporary invisible xdg_toplevel window that steals focus and grabs the clipboard.
I think we need something similar to xdg-dbus-proxy to control what messages can pass over the socket.
The current status quo for software architecture is giving a swarm of LLM agents root and full access to user data and letting them run amok, unsupervised, connected to a proprietary remote black box service either being monitored by Palantir or the CCP. What is this "paranoia" you speak of?
Everything else is cargo cult security.