Remix.run Logo
▲ ryandrake 6 hours 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 6 hours ago | parent | next [-]

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.

▲david422 6 hours ago | parent | prev | next [-]

What would you do instead?

▲vntok 4 hours ago | parent [-]

On PC, switching to QubesOS is a good start.

▲ 3 hours ago | parent [-]
[deleted]
▲afzalive 6 hours ago | parent | prev | next [-]

One simple solution is just to gate the programmatic access by confirming with the user when the app wants to read the clipboard.

▲hbn 6 hours ago | parent [-]

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 an hour ago | parent | next [-]

You need give permission to websites too. It's weird they haven't transitioned over to requiring permission on Android yet.

▲forgotusername6 5 hours ago | parent | prev [-]

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

▲ 6 hours ago | parent | prev | next [-]
[deleted]
▲pluralmonad 6 hours ago | parent | prev | next [-]

Your comment is bordlerine absurd given the utility of such a thing as copy and paste. If it is satire, then you got me.

▲krapp 6 hours ago | parent | prev | next [-]

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?

▲dzaima 5 hours ago | parent | prev [-]

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 5 hours ago | parent [-]

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.