3 ms·
Fantastic! I like that idea. I'm also exploring an option to define profiles, but also have predefines profiles that ships with the binary (e.g. Claude, then bl
by afshinmeh 7mo ago
Fantastic! I like that idea. I'm also exploring an option to define profiles, but also have predefines profiles that ships with the binary (e.g. Claude, then block all `.env` reads, etc.)
- simonw 7mo agoBeing able to mix and match profiles would be neat.
- afshinmeh 7mo agoGive me 2 days :)
- gslepak 7mo agoThe `--build-profile` / `--profile` thing is a good idea, but typically you'd want to just save all of the access that the program does without prompting. Programs will access many files and directories on startup, and it would be extremely tedious to have to manually approve each one. So you'd auto-approve all and save them to the profile. This is TOFU principles applied to sandboxing. The assumption being that "this first time I run it naked, it's unlikely to do anything malicious, let me enforce that behavior for the future."
- afshinmeh 7mo agoI agree. What would be the ideal DX from your point of view?
- gslepak 7mo agoThe DX above from @simonw seems perfectly fine. Let the user play with the app and after they exit the profile should contain all of the access attempts in a human readable format that's editable by the developer. There might be many access attempts to folders in one directory, e.g.: ~/Documents/... So instead of having a massive list of files it should be easy for developers to edit the profile to say, "Allow everything there", e.g. ~/Documents/*