2 ms·

Because often applications need to be able to read and write files that have been created by other programs. Some programs also have features which add functio

by jiggy2011 14y ago

Because often applications need to be able to read and write files that have been created by other programs. Some programs also have features which add functionality to other applications. Sometimes this can be useful , in cases such as lastpass and dropbox but other times they can be bad in cases such as spyware.

Silhouette 14y ago
Because often applications need to be able to read and write files that have been created by other programs. I challenge your position that this "often" happens. Stop and look at the different kinds of data you work with and the applications you use to work with it. I bet you'll find a lot of your applications only work with their own formats and/or a fairly small number of other common ones such as standard text/graphic file formats. Even if your applications could theoretically work with many different common formats, say a graphics editor that speaks 30 different file formats or a generic text editor that can edit many different kinds of source file, I bet in practice you only use a handful of those graphic formats or use a few different kinds of text file on any given system. Almost nothing, except for system/comms software that deals with files as black boxes without caring what kind of data they hold, needs arbitrary access to any file type. Would it really be so hard to established a systematic model for these requirements and then actively enforce it, so applications had to disclose exactly which types of data they wanted to access? This could be shown as part of a standardised installation process built into the OS, or at least summarised there and the full details made available to the user (and permissions configurable by that user) from a separate UI later. Keep in mind that to some extent this is already done. On Windows, for example, there is already a database of recognised file types and a database of associations between applications and those types. It's used when you double click on something to open it, or to decide which options to offer when you select "Open with..." on the menu. It's just only used for convenience at present, not enforced as a part of the security model. And there are already standardised install/uninstall UIs on most platforms, but again they aren't enforced so that applications have to play nicely and the OS can forcibly uninstall them in their entirety on user request. Some programs also have features which add functionality to other applications. Sure, so let them announce explicitly when they are installed that they want permission to interoperate with x, y and z other packages, and let the user say no. And make it a pull model rather than a push one: software being installed can grant permission for other software to depend on it, but not change the other software itself. That way, the main software is always in control, not the plug-ins. This is just a smaller-scale version of the principle that the OS should always be in charge of the overall system and should be able to install/uninstall/restrict/authorise any other software according to the user's wishes, and the other software doesn't get a vote.
- 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

Because often applications need to be able to read and write files that have been created by other programs. I challenge your position that this "often" happens. Stop and look at the different kinds of data you work with and the applications you use to work with it. I bet you'll find a lot of your applications only work with their own formats and/or a fairly small number of other common ones such as standard text/graphic file formats. Even if your applications could theoretically work with many different common formats, say a graphics editor that speaks 30 different file formats or a generic text editor that can edit many different kinds of source file, I bet in practice you only use a handful of those graphic formats or use a few different kinds of text file on any given system. Almost nothing, except for system/comms software that deals with files as black boxes without caring what kind of data they hold, needs arbitrary access to any file type. Would it really be so hard to established a systematic model for these requirements and then actively enforce it, so applications had to disclose exactly which types of data they wanted to access? This could be shown as part of a standardised installation process built into the OS, or at least summarised there and the full details made available to the user (and permissions configurable by that user) from a separate UI later. Keep in mind that to some extent this is already done. On Windows, for example, there is already a database of recognised file types and a database of associations between applications and those types. It's used when you double click on something to open it, or to decide which options to offer when you select "Open with..." on the menu. It's just only used for convenience at present, not enforced as a part of the security model. And there are already standardised install/uninstall UIs on most platforms, but again they aren't enforced so that applications have to play nicely and the OS can forcibly uninstall them in their entirety on user request. Some programs also have features which add functionality to other applications. Sure, so let them announce explicitly when they are installed that they want permission to interoperate with x, y and z other packages, and let the user say no. And make it a pull model rather than a push one: software being installed can grant permission for other software to depend on it, but not change the other software itself. That way, the main software is always in control, not the plug-ins. This is just a smaller-scale version of the principle that the OS should always be in charge of the overall system and should be able to install/uninstall/restrict/authorise any other software according to the user's wishes, and the other software doesn't get a vote.

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)?