6 ms·

Can't it request and be granted that permission, transparently to the app? E.g. the app does EnumerateDirectories("~/photos") then without requiring modificati

Can't it request and be granted that permission, transparently to the app? E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues? At least that's how I'd thought it would work. Perhaps this isn't viable?

weiran 20d ago
It’s how sandboxed Mac apps work today.
danielheath 20d ago
Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places. Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places. How many permission prompts will users tolerate?
- alkonaut 20d ago
  I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently. If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
- mhitza 20d ago
  If it's technically.implemented uniformely without thought of user access patterns, then yes it's a bad idea causing friction and frustration. If I drag&drop a file in an app or it's icon, or by right click. The permission would be implicit. For configuration files they could be part of allow rules, since they are so common if they follow the XDG specification. For saving files, flatpak apps could be allowed to save anywhere in the users home sub-directories (not home top-level) as long as it doesn't overwrite any existing file. There are downloads, public, documents pictures, videos, that are barely used by default. There is plenty of room for better desktop based integration, while of course lacking funding and care for users (thinking of particular devs in this case). Currently it's a mishmash of separately using flatseal (and equivalents) and having your fingers crossed if you're likely to exfiltrate or not your data.
- j1elo 19d ago
  The list of files that such app would try to access by default on initial startup would be finite and well defined. So, a Flatpak package of such app should already, if done "properly", (I'm just imagining here, not an expert) include allowed access to those paths by default.
deleted 19d ago
[deleted]

weiran 20d ago

It’s how sandboxed Mac apps work today.

danielheath 20d ago

Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places. Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places. How many permission prompts will users tolerate?

alkonaut 20d ago
I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently. If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
mhitza 20d ago
If it's technically.implemented uniformely without thought of user access patterns, then yes it's a bad idea causing friction and frustration. If I drag&drop a file in an app or it's icon, or by right click. The permission would be implicit. For configuration files they could be part of allow rules, since they are so common if they follow the XDG specification. For saving files, flatpak apps could be allowed to save anywhere in the users home sub-directories (not home top-level) as long as it doesn't overwrite any existing file. There are downloads, public, documents pictures, videos, that are barely used by default. There is plenty of room for better desktop based integration, while of course lacking funding and care for users (thinking of particular devs in this case). Currently it's a mishmash of separately using flatseal (and equivalents) and having your fingers crossed if you're likely to exfiltrate or not your data.
j1elo 19d ago
The list of files that such app would try to access by default on initial startup would be finite and well defined. So, a Flatpak package of such app should already, if done "properly", (I'm just imagining here, not an expert) include allowed access to those paths by default.

deleted 19d ago

[deleted]