zlacker

And all the file sandboxing approaches I've seen so far only seem to cater for the simple "choose a single file (or directory)" workflow and break multi-file formats, any customised UX around file I/O and any other advanced workflows.

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

>>iggldi+(OP)
The Mac sandbox grants access to the whole directory when a file is selected, iirc. I'm curious what you mean by customized UX around file I/O?

>>mike_h+j31
> The Mac sandbox grants access to the whole directory when a file is selected, iirc.

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…

>>iggldi+Xo1
Hmmm. I'd have to check. The use case given for that API (good spot) is for IDEs, where files are often in different sub-directories, so granting folder access wouldn't be enough. But you might be right, it's been a while since I looked at the details of this stuff. I do remember the bookmarks mechanism. It's all quite well thought out relative to other platforms (as per usual for Apple), but for as long as Apple treat it as an exploit mitigation mechanism rather than as a way to rapidly run untrusted code it's not going to get much traction outside the App Store where they force it.

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.