4 ms·
The capability you give an app for X doesn't have to be the raw system X. It can interpose some policy or tracking-of-use, or let you revoke just the X, or fake
by abecedarius 5y ago
The capability you give an app for X doesn't have to be the raw system X. It can interpose some policy or tracking-of-use, or let you revoke just the X, or fake the whole X to begin with, etc. This is one of the things distinguishing the object capability model from basic sandboxing. Another is that the set of kinds of X's is open-ended -- anyone can make up higher-level abstractions like an advertising server with a defined protocol, so that users who've gotta have a free ad-supported app can use one without giving it unlimited and unaudited network access.
I'd expect the store to come with standardized packages of capabilities for common kinds of apps.
- simonh 5y agoDo you really think that companies lobbying for side-loading of their apps, and getting legislation through to force it on Apple, would be satisfied with heavily locked down access to subsets of functionality? To more restricted access than App Store apps? Somehow I don't see that being acceptable to the side-loading lobby. An App Store App can be granted low level network access etc because it can be vetted and censured if found in violation of policies. Side loaded app developers will demand the same access.
- abecedarius 5y agoEvery hardware capability is potentially available in this kind of framework. It's ultimately up to the user whether an app can get at it, or with what limits. This is an inevitable source of problems for sufficiently reckless users, but it should be possible for reasonable users to keep reasonable control -- not just hacker types. A "side-loading lobby" wouldn't have grounds to demand more. (The overenthusiastic copyright lobby would probably have better luck in getting their demands wired in, going by history, but that's another issue.)