> Folders and aggregating capabilities. Some file formats don't fit into a neat folder structure where all associated files are neatly stored in a single folde

> Folders and aggregating capabilities. Some file formats don't fit into a neat folder structure where all associated files are neatly stored in a single folder underneath the "main" file. Links and sub-resource references in HTML files can go all over the directory hierarchy, as do Xref references in DWG files, and other similar things. > You could also grant access to a folder, or a set of files. This rapidly turns into "breaking workflows" or otherwise cumbersome UX, though. > For example, a filter could be written... Who writes those filters? The average user cannot be expected to do that. The OS cannot know about each and every file format's/program's peculiarities, either. Program developers know best what files they need, but are the – from that perspective – untrusted party. And how do you surface the implications of such a filter so that the user can make an intelligent decision on whether to permit that or not? > There's nothing stopping a program from having a private data file to store its configuration. Certainly, but that's orthogonal to the problem I was talking about, though.