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.

Being able to accept pastes wouldn't require any permission.

Being able to read the clipboard without the user knowing would.

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.

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.

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.

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

It doesn't have to be though. Especially on a platform that only has one UI toolkit, controlled by the vendor.

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.

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.

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

I think you're being a bit pessimistic about OS developers' abilities. Also I think you are reading more into what people are saying than they are actually saying with respect to permissions vs "programmatic access", and "applications" vs any code whatsoever.

Just to clarify my perspective on the situation: I have developed a significant amount of software for DOS, Win9x, WinXP and later, cross-platform JVM (UI and server-side), Linux (CLI, framebuffer, X11, Gtk, Qt, OpenGL, kernel modules, backend servers), HTML5+JS, embedded devices in ASM, Oracle/MySQL/Postgres/MSSQL DBs with stored procedures, probably other things I've forgotten, and a tiny bit of mobile native. I have worked with a few sandboxing/containerization systems like Docker, simple chroot, etc. Cloud hosting, AWS, OpenStack, bare metal, local systems. I have seen viruses, worms, hacks, spyware, malware, etc. affect anything with a network connection or a floppy disk drive.

I know what I am saying is possible when I say that arbitrary code should not have arbitrary access to the system-wide clipboard or filesystem until the user grants it, and that the usecases that require such broad grants are extremely uncommon.

Android provides Intents instead of FS access, but app devs all have to have their "custom experiences" that just conveniently give them significant fingerprinting, snooping, and tracking abilities.

Some Linux GUIs will already use the Gtk file picker in GNOME, and the Qt file picker in KDE.

X11 though I love it (I am working on an Xlib project right now in fact) is already a security nightmare, never mind that even highlighting text without choosing "copy" puts it into one of the system clipboards, or at least used to do so.

Even Signal now wants to force everyone to add a (likely easily brute forced by unsavory intruders) PIN so they can upload your contacts to their servers.

So yes, all the evidence points to a safer system for filesystems and clipboards and contacts and whatever else is possible, and all the evidence in threats points to it being necessary.

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.

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

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

a tinfoil hat tip: imagine the shitstorm if Apple would allow proper introspection instead of suing these companies who offer such a service. that storm would be much harder to manage now. if I'd really believe it myself I'd even say controlling the messaging was part of the reason why they sued these companies and instead are providing limited subset of such features themselves.

Wait what, they show the pop-up, but there is no permission toggle for access?

I feel like a copy/paste permission would be useless and the notification is 100x better.

Most people would click "accept" on the permission and never think about it. "Oh of course I need the ability to copy/paste on tiktok, how else will I paste 90sMusicChallenge in the search bar?"