5 ms·

This isn't just the web, there's a fundamental leakiness to the Mac's clipboard. I was horrified to realise that apps were being alerted to what was on the clip

This isn't just the web, there's a fundamental leakiness to the Mac's clipboard. I was horrified to realise that apps were being alerted to what was on the clipboard when I copied a a public key from some website and MacGPG (or whichever GPG app it was, they change) popped its head up and told me (something like) "Hi, you've copied a public key, would you like to save it in your keyring?" Does this mean that any currently running app (or maybe not even currently running, perhaps there's an event system) can see my clipboard? My feeling about this is unprintable. I started planning a clipboard app that doesn't allow this but I'm busy and I'd prefer this wasn't something I need to fix in the first place.

ma2rten 7y ago
I believe that the clipboard on windows and in x-server work the same way. Programs can also read most files including files that contain private keys.
- brigandish 7y ago
  I really care about security and lament that most people don't, but maybe they've the right idea and I'm just wasting my time. There are simply too many holes to plug :/
  - mattkrause 7y ago
    How do you want the clipboard to work then? To my mind, the whole point is to provide a way to move information within and between applications.
    - jakear 7y ago
      Would it be so hard to say “when I press command-v, send a paste event to the focused window containing my clipboard contents”? Sure some programs would want to customize keybindings, so unrestricted access could be allowed on a per-app basis, but why should any app I install have access to all of my copy events ever? Similarly for private files: MacOS already alerts you when something tries to read from “~/Desktop” for the first time, why not allow users to extend that to “~/.ssh” and “~/.gpg” too?
    - TeMPOraL 7y ago
      Yup. The fundamental problem are the evil apps that steal your keys and add ads to the text you copy. You can't take away the means for them to do it without neutering the entite system itself (an experiment in doing just that is happening on the web and in mobile space right now).
    - dredmorbius 7y ago
      Here's a stab at defining a function: The clipboard should act at an only at user direction to copy content from one application or context to another. The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. Applications, other than when clearly and unambiguously directed by the user be able to access or read clipboard contents. I'd suggest additionally that it should be possible to examine and edit within the clipboard context itself what was copied. This creates a few obvious issues, one of which is that commandline and programmatic tools for interacting with the clipboard ... won't function as transparently as they do now. A fact which would affect me directly as I make heavy use of these (xclip in Linux, pbcopy / pbpaste in MacOS, termux-clipboard-set and termux-clipboard-get in Termux/Android). I think I'd be reasonably comfortable with a confirmation dialog appearing in such cases, or having those applications specifically exempted (convenient, though some risk). The problem of programmatic interfaces to the clipboard is another matter, and those are ... probably a complex issue. Note that when working entirely within the shell, the issue largely disappears as the inter-process commmunications method is largely pipelines, files, or the shell environment (variables) themselves. With some exceptions, such as gpm(8) (a cut-and-paste utility and mouse server for virtual consols, in Linux). Though there's also behaviour of the X11/Xorg or Wayland clipboards.
      - alkonaut 7y ago
        > The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. This might feel intuitively right, but it severly limits the usefulness of the clipboard. It then becomes a basic plain text clipboard Try opening an rich text editor (e.g. https://quilljs.com/playground/ https://quilljs.com/playground/) and selecting two words of which one is bold. Hit Ctrl+C. What is now on the clipboard? What happens when you paste? You have your formatting preserved. The editor has intercepted the copy command and stored data only it knows how to create and parse. The same would happen in a diagram editor (a selected shape would perhaps be stored as some json representation), or an image editor. The problem is that the clipboard as an established concept already means "area where programs write their custom formatted data and where any app can read the same data upon paste". Restricting it might be a good idea in some cases, but it's the user expectation so it's what apps (including browsers) need to do as the default. This unfortunately means that abusing it as in the article will be possible. There is no way for the browser to know whether the changed content was formatting tags (good) or trashing the selection by adding a copyright (bad).
ridiculous_fish 7y ago
Yes, Mac apps have access to the clipboard; that's why they can paste. Is Windows or Linux different? Honest question. Please do not give Apple ideas for a "App would like to access your clipboard" dialog.
- brigandish 7y ago
  What's wrong with the system being push instead of pull? On this key combination (default cmd+V), copy the data stored in this clipboard to the currently active app's own paste buffer, which will then handle inserting the data vs All apps can read and write to the clipboard at all times World readable and writable files that often carry sensitive information sounds like a stupid idea to me.
  - frosted-flakes 7y ago
    Because the clipboard is not only accessed with the keyboard. Programs need to be able to access the clipboard so that when the yser presses the "paste" button the application can grab that data and insert it.
    - brigandish 7y ago
      The clipboard is a program. Why can the applications that want the data not make an API or file available that the clipboard uses to pass the data into, and then the app does what it will with the data? e.g. echo "this is on the clipboard" | cat - cat doesn't grab anything, it receives via a standard API, both its own and the pipe. Now imagine echo is a clipboard program that exposes no API that cat can use to access data at cat's behest. Note: As this was informative I hereby declare this a non-useless use of cat.

ma2rten 7y ago

I believe that the clipboard on windows and in x-server work the same way. Programs can also read most files including files that contain private keys.

brigandish 7y ago
I really care about security and lament that most people don't, but maybe they've the right idea and I'm just wasting my time. There are simply too many holes to plug :/
- mattkrause 7y ago
  How do you want the clipboard to work then? To my mind, the whole point is to provide a way to move information within and between applications.
  - jakear 7y ago
    Would it be so hard to say “when I press command-v, send a paste event to the focused window containing my clipboard contents”? Sure some programs would want to customize keybindings, so unrestricted access could be allowed on a per-app basis, but why should any app I install have access to all of my copy events ever? Similarly for private files: MacOS already alerts you when something tries to read from “~/Desktop” for the first time, why not allow users to extend that to “~/.ssh” and “~/.gpg” too?
  - TeMPOraL 7y ago
    Yup. The fundamental problem are the evil apps that steal your keys and add ads to the text you copy. You can't take away the means for them to do it without neutering the entite system itself (an experiment in doing just that is happening on the web and in mobile space right now).
  - dredmorbius 7y ago
    Here's a stab at defining a function: The clipboard should act at an only at user direction to copy content from one application or context to another. The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. Applications, other than when clearly and unambiguously directed by the user be able to access or read clipboard contents. I'd suggest additionally that it should be possible to examine and edit within the clipboard context itself what was copied. This creates a few obvious issues, one of which is that commandline and programmatic tools for interacting with the clipboard ... won't function as transparently as they do now. A fact which would affect me directly as I make heavy use of these (xclip in Linux, pbcopy / pbpaste in MacOS, termux-clipboard-set and termux-clipboard-get in Termux/Android). I think I'd be reasonably comfortable with a confirmation dialog appearing in such cases, or having those applications specifically exempted (convenient, though some risk). The problem of programmatic interfaces to the clipboard is another matter, and those are ... probably a complex issue. Note that when working entirely within the shell, the issue largely disappears as the inter-process commmunications method is largely pipelines, files, or the shell environment (variables) themselves. With some exceptions, such as gpm(8) (a cut-and-paste utility and mouse server for virtual consols, in Linux). Though there's also behaviour of the X11/Xorg or Wayland clipboards.
    - alkonaut 7y ago
      > The clipboard should not, nor should applications be able to, alter the copied content from the visibly-selected content. This might feel intuitively right, but it severly limits the usefulness of the clipboard. It then becomes a basic plain text clipboard Try opening an rich text editor (e.g. https://quilljs.com/playground/ https://quilljs.com/playground/) and selecting two words of which one is bold. Hit Ctrl+C. What is now on the clipboard? What happens when you paste? You have your formatting preserved. The editor has intercepted the copy command and stored data only it knows how to create and parse. The same would happen in a diagram editor (a selected shape would perhaps be stored as some json representation), or an image editor. The problem is that the clipboard as an established concept already means "area where programs write their custom formatted data and where any app can read the same data upon paste". Restricting it might be a good idea in some cases, but it's the user expectation so it's what apps (including browsers) need to do as the default. This unfortunately means that abusing it as in the article will be possible. There is no way for the browser to know whether the changed content was formatting tags (good) or trashing the selection by adding a copyright (bad).

ridiculous_fish 7y ago

Yes, Mac apps have access to the clipboard; that's why they can paste. Is Windows or Linux different? Honest question. Please do not give Apple ideas for a "App would like to access your clipboard" dialog.

brigandish 7y ago
What's wrong with the system being push instead of pull? On this key combination (default cmd+V), copy the data stored in this clipboard to the currently active app's own paste buffer, which will then handle inserting the data vs All apps can read and write to the clipboard at all times World readable and writable files that often carry sensitive information sounds like a stupid idea to me.
- frosted-flakes 7y ago
  Because the clipboard is not only accessed with the keyboard. Programs need to be able to access the clipboard so that when the yser presses the "paste" button the application can grab that data and insert it.
  - brigandish 7y ago
    The clipboard is a program. Why can the applications that want the data not make an API or file available that the clipboard uses to pass the data into, and then the app does what it will with the data? e.g. echo "this is on the clipboard" | cat - cat doesn't grab anything, it receives via a standard API, both its own and the pipe. Now imagine echo is a clipboard program that exposes no API that cat can use to access data at cat's behest. Note: As this was informative I hereby declare this a non-useless use of cat.