As long as it's function is to keep the program locked in, and not the user locked out from modifying it...
To some extent that's just laziness, because who cares for the long tail of workflows, right, and to some extent unfortunately it's a fundamental trade-off of sandboxing (the OS can't know the details of each and every file format and which files are related and need to be opened together even if the user only launched one file, the application developer does know, but is the untrusted party; being able to paste a file path directly into a GUI respectively directly edit it there can be comfortable, but it bypasses the official secure OS file picker, so again a no-go, etc. etc.).
You can find exploits on gh for older chromium versions easily
Does it, by default? https://developer.apple.com/documentation/security/app_sandb... [1] doesn't look like it, and there seem to be special features for requesting access to related files which wouldn't be necessary if selecting a file gave you access to the whole directory. Though I've got no Mac, so no idea how this actually works in practice – maybe you're right, though it'd also noticeably weaken the sandbox, which seems strange.
> I'm curious what you mean by customized UX around file I/O?
Simply things like a directory tree control integrated into the UI, IrfanView's directory switcher (when you reach the start or end of a directory while browsing through your pictures, it pops up a dialogue that allows you to easily – and without having to use the mouse – navigate up and down the directory tree to a different folder), or even something as simple text input control that allows direct editing instead of always having to go via an official OS file picker.
[1] It seems like Apple does have some support for storing relative file references after all ("document-scoped bookmarks"), so that picking something like a master project file also gives access to all related documents, no matter how complex the file format is, though I have no idea whether those really work even when moving files between different devices, and they almost certainly won't work for cross-platform file formats, because non-Mac software will of course have no idea about that kind of thing. And last time I looked, Android's and Windows's sandbox implementation didn't have anything comparable, and Linux likely doesn't, either…
There is nothing "magical" about web browsers in that regard.
I didn’t say there was anything “magical” about browsers. They have a sandbox for JavaScript, by default. Windows doesn’t have a sandbox for native apps, by default.
A parent poster seemed to be making a statement of equivalency between running a native application in Windows and running JavaScript in a browser. I don’t think they’re equivalent.
That’s what I’m saying.
My guess is that their security folks aren't convinced by the robustness of the sandbox and don't want the pain of trying to defend it, which is a pity (for them), because it just throttles their own platform and pushes people towards the web. The browser guys apparently can define a sandboxable platform: why can't Apple?
Re: custom file browsers. Yes, that's a good point. I think you can request access to whole parts of the file tree though even when sandboxed. You have to mark them as exceptions via entitlements and it's automatically granted. Because Apple see the sandbox as a way to mitigate exploits and not allow execution of untrusted code, that sort of approach works fine.