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