9 ms·

Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?

• kukx 5y ago
  It can be useful of you want to use a non standard way to paste stuff, example a right mouse button in putty.
• jchw 5y ago
  IMO: you have to look at how OSes and window systems were designed and evolved to get a great answer here. Those processes resulted in systems where the OS or compositor or window system itself can’t really know when the user is pasting something or not. It could be changed, but it would have lots of implications globally, from rewriting framework code, to changing JS APIs. Edge cases would be handled worse, like non-standard paste gestures or VM integration.
• kelnos 5y ago
  Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways that you could design the system, such as making it so the only way to paste is for the user to hit a key combination, or perhaps click on or touch a UI element that is known to be controlled/hosted/owned by the OS. Then the OS can push the clipboard contents to the foreground application, rather than the application trying to pull it. But then that becomes very limiting, UX-wise. (For example, you wouldn't be able to put a "paste" item in a context menu.) You could also have a permissions model, where the OS prompts for permission every time an app wants to fetch the clipboard contents (presumably with an "I trust this app" option to get it to stop asking). But that might be considered too intrusive, or possibly just ineffective, as people will often just mash at whatever button is closest to get a modal dialog to go away. At any rate, we have these copy/paste mechanisms from when people didn't really think about local security in the way we do today. Redesigning things would break a lot of existing applications. It might be worth it, or it might not.
  • dolmen 5y ago
    "Redesigning things would break a lot of existing applications". Only a few applications handle triggering of a Paste action by themself. Most just leave the OS/GUI framework/ handle events and only react to a Paste request event. They would not be affected if the OS stops allowing to read the clipboard while a Paste event isn't being processed.
  • BelleOfTheBall 5y ago
    Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.
    • dan-robertson 5y ago
      You don’t need to tab into the app (on a desktop os at least). It’s generally possible to read the clipboard from the background. The app mightn’t even need a visible window.
    • spiorf 5y ago
      > accidentally tab into some app I think in most systems you don't even need to do that. The app should be able to get the clipboard while in the background.
    • wruza 5y ago
      accidentally tab into some app Apps do not even have to be foreground to fetch clipboard contents, afair. On windows, a clipboard is shared with the entire session (i.e. everything that you or the system runs for you after you log on).
    • progval 5y ago
      As other pointed out, you don't even need to tab into some app. The security model on desktop OSs is that by default, every app has access to everything owned by the current user, even memory of other apps or hijacking commands by adding scripts in ~/.local/bin. It is slowly being worked on (on Linux, this is done via control groups (containerization), AppArmor, SELinux, ...) but takes time to carefully tune so legitimate existing apps don't crash because they expect access to something. IIRC, macOS and Windows are also working on this. There is also Qubes OS, taking a more radical approach of isolating everything by default, like Android or iOS. But it can be painful to use, as apps are not designed to support it.
• lcnmrn 5y ago
  Clipboard should be a private and secure enclave (encrypted) in the first place. Only the OS should store and retrieve data from it.
  • Gigachad 5y ago
    It’s pretty safe in web browsers. Any app can write to it but the only way to read is if the user hits the paste shortcut.
    • edave64 5y ago
      That is not quite true. JS can read the clipboard on any direct user interaction using "Document.execCommand". Also, there is a newer Clipboard API that requires explicit user permission, but as far as I understand once it is given it allows arbitrary reads.
      • kalleboo 5y ago
        This depends on the browser. In a privacy-conscious browser such as Safari, it will pop up a browser-controlled "paste" context menu that the user has to explicitly interact with.
      • marcosdumay 5y ago
        On my browser (Firefox 96), the paste command seems to just return false and do nothing.
        • edave64 5y ago
          Are you running it as part of a click handler?
          • marcosdumay 5y ago
            No, I was trying it on the console, without any context.
• tonyg 5y ago
  Indeed. Our OS security models will keep being broken until people start taking object capability design seriously ¯\_(ツ)_/¯