4 ms·

A lot of file formats [1] don't store their data in a single, atomic file that the user can simply pick and thereby grant the program access to it – how do you

A lot of file formats [1] don't store their data in a single, atomic file that the user can simply pick and thereby grant the program access to it – how do you propose handling those without either breaking workflows or else substantially weakening the file access sandbox? [1] Multi-part archives, multi-part video files, playlists, videos with separate subtitle files, HTML documents containing links to other local HTML documents or referencing various sub-resources (images/videos/audio/style sheets/scripts/...), Audacity projects, images with metadata in external sidecar files, ditto for georeferenced images, QGIS projects, AutoCAD's lock file implementation, DWG files as such, …

mikewarot 5y ago
Folders and aggregating capabilities. For example, a filter could be written that takes an input of full access to a file, and only permits read access, or access to any specified set of bytes, etc. These could be stacked, like piping with Unix. You could also grant access to a folder, or a set of files. There's nothing stopping a program from having a private data file to store its configuration. However, this could lead to the same issues web browsers have now with cookies, cross boundary scripts, etc. The main thing is to make it as transparent for the user as possible to see what's in a given capability. This is all too theoretical for me, I need to get a better handle on it. I've tried to get Genode running, the most recent attempt in which I learned my Windows drive was encrypted... 8( That's fixed, I'll try again soonish.
- iggldiggl 5y ago
  > 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.

mikewarot 5y ago

Folders and aggregating capabilities. For example, a filter could be written that takes an input of full access to a file, and only permits read access, or access to any specified set of bytes, etc. These could be stacked, like piping with Unix. You could also grant access to a folder, or a set of files. There's nothing stopping a program from having a private data file to store its configuration. However, this could lead to the same issues web browsers have now with cookies, cross boundary scripts, etc. The main thing is to make it as transparent for the user as possible to see what's in a given capability. This is all too theoretical for me, I need to get a better handle on it. I've tried to get Genode running, the most recent attempt in which I learned my Windows drive was encrypted... 8( That's fixed, I'll try again soonish.

iggldiggl 5y ago
> 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.