3 ms·

Maybe I'm missing something but a clipboard permission seems to be pretty useless for most apps. When I want to login I have to paste my password, when I want

by dewey 6y ago

Maybe I'm missing something but a clipboard permission seems to be pretty useless for most apps. When I want to login I have to paste my password, when I want to paste an email address into a Linkedin chat I need the clipboard. So everyone would just grant that permission anyway as it makes a lot of apps useless without and they'd just continue their harvesting after that. It would be a very small percentage to selectively enable/disable the clipboard permissions for certain tasks.

mixmastamyk 6y ago
Pasting to the clipboard into a standard widget is different than reading/writing it. Hopefully in mobile OS as well.
Vvector 6y ago
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.
  - 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.
RandallBrown 6y ago
Being able to accept pastes wouldn't require any permission. Being able to read the clipboard without the user knowing would.

by dewey 6y ago

mixmastamyk 6y ago

Pasting to the clipboard into a standard widget is different than reading/writing it. Hopefully in mobile OS as well.

Vvector 6y ago

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.
- 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.

RandallBrown 6y ago

Being able to accept pastes wouldn't require any permission. Being able to read the clipboard without the user knowing would.