3 ms·

No, I use countless file formats with countless different programs. This is especially important if you want to work in a Unix style. Friends who do graphics o

by jiggy2011 14y ago

No, I use countless file formats with countless different programs. This is especially important if you want to work in a Unix style. Friends who do graphics or audio work do the same thing. This sounds like a complex solution that would require every program to know which other programs might want to interact with it's particular files. You also have programs like text editors and hex editors which don't necessarily even know which file types they will need to work with.

Silhouette 14y ago
This sounds like a complex solution that would require every program to know which other programs might want to interact with it's particular files. I don't see why. Any application can register its own file types, and gets full access to files of those types by default. Allow for common file types to be registered as well (the OS provider could start with a list) and some basic grouping ("all text files", "all files") and you've got a reasonably sensible underlying model that wouldn't need a lot of exceptions to be manually permitted once set up and wouldn't need to present users with vast lists of types at installation time. As I said, we're part way there already. Most OSes these days have some concept of "known types" and the applications associated with them. There are already conventions for things like where applications should store their configuration data on each platform. There are obviously app stores, distro mirrors and such that can cope with installing/uninstalling entire applications including all sorts of horrendous dependency management, so incorporating a simple file type system in there as well doesn't seem so hard. Given the vast potential benefits to system robustness and security of locking these things down properly, I think you're awfully quick to assume the solution would be too complex to be workable. Compared to the horrors of file ownership and user/group systems on various modern platforms, it's practically a walk in the park. ;-)
- jiggy2011 14y ago
  What you are doing is adding an extra dimension to your permissions vector, instead of just worrying about which users can access what you have to think about individual programs. There are already implementations of this, for example SELinux. It difficulties in that how do I know which files a particular program might need and how is this implemented at a UI level? For example, what if a program asks for permissions on PNG files? Is this because it wants to manipulate them or is it simply that some of it's internal assets are stored as PNGs? What happens if I add a plugin or update to a program that allows it to work with different file types? How do you prevent "dick moves" like a new program locking other programs out of a file type it decides to claim? How do you implement the UI? Is it some central permissions manager or do you have endless popups (which people are likely to just unthinkingly click accept on)?

Silhouette 14y ago

This sounds like a complex solution that would require every program to know which other programs might want to interact with it's particular files. I don't see why. Any application can register its own file types, and gets full access to files of those types by default. Allow for common file types to be registered as well (the OS provider could start with a list) and some basic grouping ("all text files", "all files") and you've got a reasonably sensible underlying model that wouldn't need a lot of exceptions to be manually permitted once set up and wouldn't need to present users with vast lists of types at installation time. As I said, we're part way there already. Most OSes these days have some concept of "known types" and the applications associated with them. There are already conventions for things like where applications should store their configuration data on each platform. There are obviously app stores, distro mirrors and such that can cope with installing/uninstalling entire applications including all sorts of horrendous dependency management, so incorporating a simple file type system in there as well doesn't seem so hard. Given the vast potential benefits to system robustness and security of locking these things down properly, I think you're awfully quick to assume the solution would be too complex to be workable. Compared to the horrors of file ownership and user/group systems on various modern platforms, it's practically a walk in the park. ;-)

jiggy2011 14y ago
What you are doing is adding an extra dimension to your permissions vector, instead of just worrying about which users can access what you have to think about individual programs. There are already implementations of this, for example SELinux. It difficulties in that how do I know which files a particular program might need and how is this implemented at a UI level? For example, what if a program asks for permissions on PNG files? Is this because it wants to manipulate them or is it simply that some of it's internal assets are stored as PNGs? What happens if I add a plugin or update to a program that allows it to work with different file types? How do you prevent "dick moves" like a new program locking other programs out of a file type it decides to claim? How do you implement the UI? Is it some central permissions manager or do you have endless popups (which people are likely to just unthinkingly click accept on)?