6 ms·

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).
      - dredmorbius 7y ago
        If you want to pass rich text or spreadsheet cell formulae, display those before selecting. Which puts the onus on the application to provide that functionality. That preserves the functionality, respects the "copy visibly-selected content" directive, and makes clear just what is being saved to the clipboard, making sneak attacks more difficult. Argument that the clipboard behaves in a way that is demonstrably prone to malicious attack is simply argument from tradition. Yes, that's how things have been done. We're discovering that how things have been done leads to strongly negative consequences.
        alkonaut 7y ago
        Not sure I follow, how should the argument display the rich text (markup/formatting instructions) before the selection? The displayed/selected content might be Foo Bar but the content I want on the clipboard could be Foo <i>Bar</i> but I never want to see the markup, only the formatted text. I don’t want to make a two step function where I need to reveal a textual description of the content and select that. The markup might be a base64 encoded piece of binary gibberish in the case of a visual diagram for example.

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).
    - dredmorbius 7y ago
      If you want to pass rich text or spreadsheet cell formulae, display those before selecting. Which puts the onus on the application to provide that functionality. That preserves the functionality, respects the "copy visibly-selected content" directive, and makes clear just what is being saved to the clipboard, making sneak attacks more difficult. Argument that the clipboard behaves in a way that is demonstrably prone to malicious attack is simply argument from tradition. Yes, that's how things have been done. We're discovering that how things have been done leads to strongly negative consequences.
      - alkonaut 7y ago
        Not sure I follow, how should the argument display the rich text (markup/formatting instructions) before the selection? The displayed/selected content might be Foo Bar but the content I want on the clipboard could be Foo <i>Bar</i> but I never want to see the markup, only the formatted text. I don’t want to make a two step function where I need to reveal a textual description of the content and select that. The markup might be a base64 encoded piece of binary gibberish in the case of a visual diagram for example.