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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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?
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 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.
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.
GrapheneOS recently added secure paste: https://grapheneos.org/features#secure-paste
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.
All programs must be open source and distributed as source.
Everything else is cargo cult security.
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.
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
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.
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.
For what it's worth, grapheneos allows you to control this permission.
iOS too
Why would the Belgian post hack your phone?!? Of all the things to be suspicious of, that one's low on my list.
You never know, Sezsett might be a big fry.
Yeah agreed. The Toast notification is terrible UX. Thanks for letting me know an app already read my address/CC number/privatemessage/image.
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.
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.
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.
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.
What would you do instead?
On PC, switching to QubesOS is a good start.
One simple solution is just to gate the programmatic access by confirming with the user when the app wants to read the clipboard.
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.
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
Your comment is bordlerine absurd given the utility of such a thing as copy and paste. If it is satire, then you got me.
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?
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.
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.