3 ms·

The clipboard is controlled by the OS. When you 'paste' the OS sends the contents to the app. There is no need for an app to have access to the clipboard.

filleduchaos 6y ago
I'm curious - have you ever actually looked into how clipboards work across various OSes? Because programmatic clipboard access is the norm pretty much across the board.
- nitrogen 6y ago
  It doesn't have to be though. Especially on a platform that only has one UI toolkit, controlled by the vendor.
  - filleduchaos 6y ago
    Ah, so _now_ we're asking Apple to disallow any UI development whatsoever outside of using the components in the UIKit and AppKit SDKs (and screw you if you want to develop any sort of interface that's not supported or intended to be supported out of the box by the above)? Very interesting indeed. I understand the outrage over programs abusing the resources they have access to, but frankly this is just approaching hysteria. This is the equivalent of reading an article about an app snooping at documents you didn't open for sensitive data and jumping to the conclusion that operating systems should not support programmatic access to the filesystem.
    - leppr 6y ago
      I'll give a similar reply as I did to your other comment: the most popular platform for interacting with low-trust applications, the web, sanely does not allow apps to access your whole filesystem. It would have never thrived as it did if users had to limit themselves to a small selection of vendors they can thrust with their whole system. There's a huge difference in usage between apps on desktop OSs, which are often of less commercial nature, open-source, and more carefully vetted by centralized gatekeepers, and the mobile app ecosystem, where any random fast food chain will entice you to install their app to make an online order. The smartphone app ecosystem has to be low trust, like the web.
      - filleduchaos 6y ago
        > the most popular platform for interacting with low-trust applications, the web, sanely does not allow apps to access your whole filesystem. Yes, obviously, arbitrary code that is executed from over the network at a time you can't fully control and programs that you install and run on the device that you own have different levels of trust. Are you seriously making the argument that code from https://facebook.com https://facebook.com running within your browser cannot access your filesystem then that means every single executable on your machine should be incapable of doing that as well? Wasn't this the same site that complained to high heavens about the constant permission prompts in macOS Catalina? > which are often of less commercial nature, open-source, and more carefully vetted by centralized gatekeepers I'm sorry, this is just blatantly false (as literally decades of malware on the desktop can attest).
    - nitrogen 6y ago
      You seem pretty moved by this discussion. What is your use case that is broken by protecting the clipboard and filesystem? using the components in the UIKit and AppKit SDKs Yes, if you want to provide a native feel, with native features like clipboards, and native accessibility features, use the native widgets. They usually tend to be stylable any way you want (my UI experience is with HTML, Qt, Swing, Win32, Winforms, and Gtk; I'd be very surprised if Android and iOS don't support widget styling). Just like on the web, it's a big problem when people reimplement a text input box from scratch. operating systems should not support programmatic access to the filesystem. This is the direction desktops are going, and it's where Android and iOS started. I shouldn't have to give a chat app access to all of my photos, videos, music, and documents just to let it download messages. And to upload a photo, both Android and iOS provide system file pickers. Desktop/laptop OS sandboxes should also provide file pickers to give an app access to one file or one directory. An app doesn't need to access my clipboard until I'm trying to paste something in that app, or I know that it does something useful (and nothing nefarious) with clipboard snooping. It looks like iOS has provided clipboard notification events for different media types so that apps can show a Paste button without having to read the actual contents until the user is ready.
      - filleduchaos 6y ago
        > You seem pretty moved by this discussion. What is your use case that is broken by protecting the clipboard and filesystem? Yes, I am pretty moved, because this is ostensibly a technical audience and the level of sheer "I don't know how my operating system works" I'm seeing here is quite alarming indeed. I don't have to have a particular use case to point out that "applications should not be able to access the filesystem at all" is plain silly. > Yes, if you want to provide a native feel, with native features like clipboards, and native accessibility features, use the native widgets. So basically any application that does not use native widgets should have zero accessibility or platform functionality. That's most of the gaming industry out the window then, as well as anybody building user interfaces that an operating system does not (yet) support. Additionally, god forbid you be able to copy and paste on operating systems that don't have native widget toolkits (such as, say, Linux), or even implement toolkits for such platforms in the first place. Am I permitted to call this a hysterical overreaction yet? > This is the direction desktops are going, and it's where Android and iOS started. Neither Android nor iOS have ever prevented programmatic access to the filesystem. You seem to constantly conflate programmatic access and permissions/sandboxing, which is precisely the sort of mistake that "moves" me to see from people who develop software. > Desktop/laptop OS sandboxes should also provide file pickers to give an app access to one file or one directory. I'm _very_ interested in how exactly the command-line tools you use would work with using file pickers to grant them access to single files and folders. Also very interested in how Linux, an operating system that explicitly does not provide a widget toolkit, is supposed to provide file pickers to the variety of programs that run on it. > An app doesn't need to access my clipboard until I'm trying to paste something in that app A clipboard is a shared buffer. If something is supposed to be secret, don't put it in the shared buffer between all applications. Applications will continue to have the ability to query/read clipboards they have access to (for, amongst other things, actually implementing a paste), much like computers will continue to have the ability to read/query network drives that they have access to - that's the literal point of having a clipboard/network drive. Discussing permissions and sandboxing (which most clipboard implementations already do, with app-local and/or named clipboards distinct from the system-wide clipboard) is one thing, but claiming that programs should not be able to interact with clipboard contents via code is frankly rather ridiculous.
- leppr 6y ago
  Except on the most popular application platform available of today: the web. Imagine if every website could read your system clipboard at will. I'm honestly amazed and horrified to learn that smartphone apps on the 2 OSs have this capability. This capability, used legitimately, can only bring a very, very slight UX improvement. At this point, we know smartphone apps exploit any avenue they have to extract data from their users, regardless of the perceived ethicality of their vendor. The smartphone vendors more than any others know this. If there's an entity to direct the blame towards it's Apple and Google for allowing this, when fixing it on their part would be so trivial.
  - filleduchaos 6y ago
    > Except on the most popular application platform available of today: the web. The web is not an operating system, for goodness' sake. A browser is itself an application no different from a terminal emulator + shell (which also is capable of running arbitrary other applications within its context). > I'm honestly amazed and horrified to learn that smartphone apps on the 2 OSes have this capability. Prepare to be even more "amazed" and "horrified": I am willing to bet that whatever desktop OS/distro you use does the same damn thing (providing apps with programmatic access to the clipboard or clipboards). If you don't want other applications to access some data, for heaven's sake don't put it in what is literally a shared buffer between applications.

filleduchaos 6y ago

I'm curious - have you ever actually looked into how clipboards work across various OSes? Because programmatic clipboard access is the norm pretty much across the board.

nitrogen 6y ago
It doesn't have to be though. Especially on a platform that only has one UI toolkit, controlled by the vendor.
- filleduchaos 6y ago
  Ah, so _now_ we're asking Apple to disallow any UI development whatsoever outside of using the components in the UIKit and AppKit SDKs (and screw you if you want to develop any sort of interface that's not supported or intended to be supported out of the box by the above)? Very interesting indeed. I understand the outrage over programs abusing the resources they have access to, but frankly this is just approaching hysteria. This is the equivalent of reading an article about an app snooping at documents you didn't open for sensitive data and jumping to the conclusion that operating systems should not support programmatic access to the filesystem.
  - leppr 6y ago
    I'll give a similar reply as I did to your other comment: the most popular platform for interacting with low-trust applications, the web, sanely does not allow apps to access your whole filesystem. It would have never thrived as it did if users had to limit themselves to a small selection of vendors they can thrust with their whole system. There's a huge difference in usage between apps on desktop OSs, which are often of less commercial nature, open-source, and more carefully vetted by centralized gatekeepers, and the mobile app ecosystem, where any random fast food chain will entice you to install their app to make an online order. The smartphone app ecosystem has to be low trust, like the web.
    - filleduchaos 6y ago
      > the most popular platform for interacting with low-trust applications, the web, sanely does not allow apps to access your whole filesystem. Yes, obviously, arbitrary code that is executed from over the network at a time you can't fully control and programs that you install and run on the device that you own have different levels of trust. Are you seriously making the argument that code from https://facebook.com https://facebook.com running within your browser cannot access your filesystem then that means every single executable on your machine should be incapable of doing that as well? Wasn't this the same site that complained to high heavens about the constant permission prompts in macOS Catalina? > which are often of less commercial nature, open-source, and more carefully vetted by centralized gatekeepers I'm sorry, this is just blatantly false (as literally decades of malware on the desktop can attest).
  - nitrogen 6y ago
    You seem pretty moved by this discussion. What is your use case that is broken by protecting the clipboard and filesystem? using the components in the UIKit and AppKit SDKs Yes, if you want to provide a native feel, with native features like clipboards, and native accessibility features, use the native widgets. They usually tend to be stylable any way you want (my UI experience is with HTML, Qt, Swing, Win32, Winforms, and Gtk; I'd be very surprised if Android and iOS don't support widget styling). Just like on the web, it's a big problem when people reimplement a text input box from scratch. operating systems should not support programmatic access to the filesystem. This is the direction desktops are going, and it's where Android and iOS started. I shouldn't have to give a chat app access to all of my photos, videos, music, and documents just to let it download messages. And to upload a photo, both Android and iOS provide system file pickers. Desktop/laptop OS sandboxes should also provide file pickers to give an app access to one file or one directory. An app doesn't need to access my clipboard until I'm trying to paste something in that app, or I know that it does something useful (and nothing nefarious) with clipboard snooping. It looks like iOS has provided clipboard notification events for different media types so that apps can show a Paste button without having to read the actual contents until the user is ready.
    - filleduchaos 6y ago
      > You seem pretty moved by this discussion. What is your use case that is broken by protecting the clipboard and filesystem? Yes, I am pretty moved, because this is ostensibly a technical audience and the level of sheer "I don't know how my operating system works" I'm seeing here is quite alarming indeed. I don't have to have a particular use case to point out that "applications should not be able to access the filesystem at all" is plain silly. > Yes, if you want to provide a native feel, with native features like clipboards, and native accessibility features, use the native widgets. So basically any application that does not use native widgets should have zero accessibility or platform functionality. That's most of the gaming industry out the window then, as well as anybody building user interfaces that an operating system does not (yet) support. Additionally, god forbid you be able to copy and paste on operating systems that don't have native widget toolkits (such as, say, Linux), or even implement toolkits for such platforms in the first place. Am I permitted to call this a hysterical overreaction yet? > This is the direction desktops are going, and it's where Android and iOS started. Neither Android nor iOS have ever prevented programmatic access to the filesystem. You seem to constantly conflate programmatic access and permissions/sandboxing, which is precisely the sort of mistake that "moves" me to see from people who develop software. > Desktop/laptop OS sandboxes should also provide file pickers to give an app access to one file or one directory. I'm _very_ interested in how exactly the command-line tools you use would work with using file pickers to grant them access to single files and folders. Also very interested in how Linux, an operating system that explicitly does not provide a widget toolkit, is supposed to provide file pickers to the variety of programs that run on it. > An app doesn't need to access my clipboard until I'm trying to paste something in that app A clipboard is a shared buffer. If something is supposed to be secret, don't put it in the shared buffer between all applications. Applications will continue to have the ability to query/read clipboards they have access to (for, amongst other things, actually implementing a paste), much like computers will continue to have the ability to read/query network drives that they have access to - that's the literal point of having a clipboard/network drive. Discussing permissions and sandboxing (which most clipboard implementations already do, with app-local and/or named clipboards distinct from the system-wide clipboard) is one thing, but claiming that programs should not be able to interact with clipboard contents via code is frankly rather ridiculous.
leppr 6y ago
Except on the most popular application platform available of today: the web. Imagine if every website could read your system clipboard at will. I'm honestly amazed and horrified to learn that smartphone apps on the 2 OSs have this capability. This capability, used legitimately, can only bring a very, very slight UX improvement. At this point, we know smartphone apps exploit any avenue they have to extract data from their users, regardless of the perceived ethicality of their vendor. The smartphone vendors more than any others know this. If there's an entity to direct the blame towards it's Apple and Google for allowing this, when fixing it on their part would be so trivial.
- filleduchaos 6y ago
  > Except on the most popular application platform available of today: the web. The web is not an operating system, for goodness' sake. A browser is itself an application no different from a terminal emulator + shell (which also is capable of running arbitrary other applications within its context). > I'm honestly amazed and horrified to learn that smartphone apps on the 2 OSes have this capability. Prepare to be even more "amazed" and "horrified": I am willing to bet that whatever desktop OS/distro you use does the same damn thing (providing apps with programmatic access to the clipboard or clipboards). If you don't want other applications to access some data, for heaven's sake don't put it in what is literally a shared buffer between applications.