2 ms·
I think that "feed fake data" is the wrong way to do it. The good way should be something like "feed data from alternate source", where the alternate source can
by zzo38computer 3y ago
I think that "feed fake data" is the wrong way to do it. The good way should be something like "feed data from alternate source", where the alternate source can be any other program. This other source could be anything that the user wants to put in by that other programs, such as: empty data, random data, fake but consistent data, data from an alternate file (e.g. a separate contacts list, or a picture from a file instead of from the camera), transformed in some way (e.g. turning a picture from a camera upside-down), filtered, logged, or asking the user every time for each individual piece of data, feeding error codes instead of data (and allowing the user to specify which error codes), etc. (This should include everything even the current date/time access.)
This is useful for better user control and for purposes of testing and accessibility purposes.
(My own idea of operating system design, one of the ideas involved (there are many other ideas, but most of them are not relevant here) is the "proxy capabilities", with capability-based security including proxy capabilities; all I/O uses it, and it can also be used in a better way than the UNIX pipes (using the command shell), and in other ways. This also includes even the date/time. No system calls other than Yield and Quit can be used without being given a capability key.
- nine_k 3y agoI think this is the best approach, and the only really workable approach. Very often it's too hard for an app developer to play nicely with an unavailable permission, and it makes testing vastly larger and harder for a relatively marginal set of users, so smaller commercial apps mostly won't care to play nicely. Granting the permission bu feeding an alternative data source is easiest for both parties, the developers and the users. It, of course, will make some scams easier, too. Prepare for banks to use more complex device-enlisting procedures, for instance.