5 ms·

> what, exactly, constitutes "direct user request" that both... > 1) does not break common programming techniques (e.g. an application rolling its own GUI, or

• 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.
  • sgc 6y ago
    Although I understand your point on the shared buffer, I don't see how else I can share information between two arbitrary apps not explicitly designed for it. Perhaps I should be able to use settings to require an os confirmation dialog, at least for info not copied into the clipboard by the same app, much as users can use noscript. As for Linux, if they don't want to deal with the clipboard, then users need to understand (and should have already) that a buffet style open source ecosystem does come with some risks and rewards that make it a different security paradigm from a centralized os with a lot of basic tools/apps made by the os provider. Do you have some idea of a better, more secure way to share information between two apps the user alone has decided should be in communication?
    • filleduchaos 6y ago
      Between two or more known apps, a solution already exists - don't put in the system-wide shared buffer, put it in a buffer whose access is restricted to apps that you know. For example, on iOS you've been able to create team-local (only accessible from apps with the same team ID) and app-local (created with a unique identifier so only your app knows & can interact with it) clipboards since...a very long time, definitely pre-iOS 8 because that's when I encountered the API the first time. To some extent, a solution does exist for arbitrary (iOS and Android) apps, which lets you explicitly pick what application you want to receive some data - the sharesheet. It's criminally underused in my opinion.
  • ebg13 6y ago
    > How does this work for clicking on a UI element to paste? The same way as designating keybindings. Registration with the OS. I don't care if you have to do it by defining hotspot outlines for bespoke-from-raw-pixels interface elements. > How does this work for using non-tactile forms of input - say, a voice command? Voice interface is mediated by the OS. Register your desired custom paste command. > the very real and undebatable need to allow programs to simulate keyboard events? False. I'm happy to debate it. But before we do, I have to ask you to try to not be stuck in the "how things are done now" mindset. > What happens to operating systems that have the implementation of a system clipboard as out of scope" Then they have decided to punt on user safety. Be angry at them and demand better. Also, you're derailing. > what, exactly, do you think happens when (for example) a C program calls `getchar()`? What do YOU think happens? You think that your program talks directly to your keyboard buttons? And why do you think that this question is relevant? > 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? Frankly, I think this is a bullshit user-hostile copout. Treating the clipboard as "general shared buffer between applications" is exactly what caused this madness. The clipboard is an extension of the user, like writing something down on paper so they can then reading it back later, and should be treated as such with sanctity. Try approaching from the perspective that all of your "what if"s have a safe non-almost-100%-of-the-time-user-hostile solution. Because the freewheeling "steal my secrets" API is almost 100% of the time extremely user hostile and computers are meant for people to use.