7 ms·

> Still don't understand why clipboard-sniffing isn't behind a permissions flag. Screw permissions flags. Clipboard-sniffing is never justified. Moving data ou

by ebg13 6y ago

> Still don't understand why clipboard-sniffing isn't behind a permissions flag. Screw permissions flags. Clipboard-sniffing is never justified. Moving data out of the clipboard should only ever happen by direct user request via the OS interaction layer.

leephillips 6y ago
This is so obviously, blindingly true that I am amazed it’s even possible for apps to do this.
- 0xEFF 6y ago
  Launchbar and Dash on the mac both have great clipboard features. I use it many times a day. For example, a snippet to drop a markdown formatted link with the title from the first clipboard stack entry and the URL from the second clipboard stack entry.
  - ebg13 6y ago
    Nothing that you just said requires sniffing the clipboard contents without you initiating the transfer.
_bxg1 6y ago
I would tend to agree, but a handful of people have a handful of reasons why they like it, and so removing it completely isn't as much of a no-brainer as adding a permission dialog is.
- ebg13 6y ago
  Sure, but the reasons are always so...contrived and frivolous...and none of them require accessing the clipboard automatically without the user invoking a system command. And the consequence of these poorly considered objections is what we have now. It's like people have either been gaslit into thinking that there's no sane alternative to the current nightmare or are so shortsighted that they don't understand the horrors lurking around every corner that wouldn't be there if they stopped to consider the consequences of [checks notes] "google maps doesn't require you to to paste the address in before it starts to route" and "dash can drop a markdown formatted link". Because saving you one click is surely _so_ important that it's worth giving up everything for.
filleduchaos 6y ago
And what, exactly, constitutes "direct user request" that both 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings) and 2) is not trivially spoofable by the enterprising developer? I understand the outrage over apps abusing their access to the clipboard but what I don't understand is the people acting as though the OSes they use on the daily don't have the exact same "flaw".
- ebg13 6y ago
  > what, exactly, constitutes "direct user request" that both... > 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings) A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS. Want something perpetually backgrounded that exists exclusively to steal your secrets? Make _that_ a special permission if you must. Or just don't allow it. > * 2) is not trivially spoofable by the enterprising developer?* Ignoring the _minor_ contradiction of mixing "trivially" and "enterprising", rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that. Could someone root your system and blahblahblah? Sure. But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
  - filleduchaos 6y ago
    > A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS. Wonderful! Now how does this brilliant little solution account for applications that don't centre their operations on the keyboard? How does this work for clicking on a UI element to paste? How does this work for using non-tactile forms of input - say, a voice command? How does this work for any method of interaction that's not "press a combination of keys"? How does this interact with the very real and undebatable need to allow programs to simulate keyboard events? What happens to operating systems that have the implementation of a system clipboard as out of scope (like a little-known operating system called Linux)? How does, say, the X window server then manage to implement a clipboard on top of it? > rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that. I am very curious indeed: what, exactly, do you think happens when (for example) a C program calls `getchar()`? > But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow. If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications? The whole point of a buffer for temporarily storing and transferring data between applications is for said applications to actually access it. You are doing the equivalent of saving your "secret" in plaintext in your home folder and then complaining about the OS if/when a program peeks through your generally accessible home folder and finds it.

by ebg13 6y ago

leephillips 6y ago

This is so obviously, blindingly true that I am amazed it’s even possible for apps to do this.

0xEFF 6y ago
Launchbar and Dash on the mac both have great clipboard features. I use it many times a day. For example, a snippet to drop a markdown formatted link with the title from the first clipboard stack entry and the URL from the second clipboard stack entry.
- ebg13 6y ago
  Nothing that you just said requires sniffing the clipboard contents without you initiating the transfer.

_bxg1 6y ago

I would tend to agree, but a handful of people have a handful of reasons why they like it, and so removing it completely isn't as much of a no-brainer as adding a permission dialog is.

ebg13 6y ago
Sure, but the reasons are always so...contrived and frivolous...and none of them require accessing the clipboard automatically without the user invoking a system command. And the consequence of these poorly considered objections is what we have now. It's like people have either been gaslit into thinking that there's no sane alternative to the current nightmare or are so shortsighted that they don't understand the horrors lurking around every corner that wouldn't be there if they stopped to consider the consequences of [checks notes] "google maps doesn't require you to to paste the address in before it starts to route" and "dash can drop a markdown formatted link". Because saving you one click is surely _so_ important that it's worth giving up everything for.

filleduchaos 6y ago

And what, exactly, constitutes "direct user request" that both 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings) and 2) is not trivially spoofable by the enterprising developer? I understand the outrage over apps abusing their access to the clipboard but what I don't understand is the people acting as though the OSes they use on the daily don't have the exact same "flaw".

ebg13 6y ago
> what, exactly, constitutes "direct user request" that both... > 1) does not break common programming techniques (e.g. an application rolling its own GUI, or implementing its own modes/keybindings) A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS. Want something perpetually backgrounded that exists exclusively to steal your secrets? Make _that_ a special permission if you must. Or just don't allow it. > * 2) is not trivially spoofable by the enterprising developer?* Ignoring the _minor_ contradiction of mixing "trivially" and "enterprising", rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that. Could someone root your system and blahblahblah? Sure. But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow.
- filleduchaos 6y ago
  > A callback method that you can define to do anything you want in your program when the OS hands you the result of a user initiated paste operation because your program had focus. If you want custom keybindings to initiate the paste operation, you can register that desire with the OS. Wonderful! Now how does this brilliant little solution account for applications that don't centre their operations on the keyboard? How does this work for clicking on a UI element to paste? How does this work for using non-tactile forms of input - say, a voice command? How does this work for any method of interaction that's not "press a combination of keys"? How does this interact with the very real and undebatable need to allow programs to simulate keyboard events? What happens to operating systems that have the implementation of a system clipboard as out of scope (like a little-known operating system called Linux)? How does, say, the X window server then manage to implement a clipboard on top of it? > rolling your own GUI and defining keybindings doesn't mean that you control access to the interface. The operating system mediating the hardware does that. I am very curious indeed: what, exactly, do you think happens when (for example) a C program calls `getchar()`? > But let's stop making "steal my secrets" part of the fucking standard system API and start working toward a brighter tomorrow. If you consider something a secret, then may I suggest that you don't (both as a user and as a developer) put it in the general shared buffer for applications? The whole point of a buffer for temporarily storing and transferring data between applications is for said applications to actually access it. You are doing the equivalent of saving your "secret" in plaintext in your home folder and then complaining about the OS if/when a program peeks through your generally accessible home folder and finds it.