Hacker News Reader

Comment by asplake | Hacker News Reader

Does this recurring problem suggest a missing API?

When I saw this video of a lot more apps doing it, I did wonder if it actually might be a commonly used third-party library causing this. It's certainly possible.

https://www.youtube.com/watch?v=pRSWdtoUAjo

Make clipboard behave like a channel[+], like GNOME native apps do, additionally require a standard paste command to paste, then this clipboard attack will be impossible to conduct.

[+]:A sample pipe might be a good analogy for this behaviour. You cut or copy the input, send through the sample pipe, and the receiving end unpacks, receiving itself makes the sample disappear for further use. Multiple samples could be sent through the pipe, though the pipe should behave in a LIFO, no sample adding allowed after removal starts, manner if this is desired.

Alternatively, encrypt the contents of the clipboard at rest.

GNOME is based on X11, which _very_ much grants programmatic access to the clipboard to pretty much any application that asks.

Seriously, has anyone complaining about this actually paid any attention to how clipboards work on their OSes before this?

> to how clipboards work on their OSes before this?

GNOME has a Wayland implementation too, and what I said only applies to GNOME native apps.

GtkClipboard, like many, many other clipboard implementations, provides programmatic access to applications[0].

I am thus very curious indeed about how a "GNOME native" app differs in this context.

0. https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html

Not unless you think PrivacyInvasionFramework should be a thing.

Yes.

It would all be a lot simpler if browsers and other operating systems just implemented an API call for obtainAllMyPrivateInformation(). That's clearly what developers like LinkedIn (and TicToc, etc.) are looking for.

Reply on news.ycombinator.com