Here's how Android could fix its permission system:
Take contact lists as an example.
Many programs request access to your contact list. Usually, this is so that they can display back to you a contact picker that lets you choose some set of contents which you want to share with, or otherwise invite to use the app. A few bad apps will just spam your contacts without your approval.
How could we make this more secure? Well, imagine that Android itself implemented a contact picker API. Instead of requesting access to contacts upfront, a program would call an API to say "Please ask the user to select some contacts for purpose X". The platform itself would then render a contact picker UI, and the user would pick some contacts. Only the chosen contacts would be returned to the app.
As far as the user is concerned, for legitimate apps, the UX I described is exactly the same as what they get now, except that the app doesn't have to request general access to the user's contact list upfront, and thus the whole thing is more secure. It's strictly superior! And this approach -- of inferring security from decisions the user is making anyway, by making those decisions happen in privileged UIs rendered by the platform -- turns out to extend to far more than just contacts.
This is the model I'm currently implementing in https://sandstorm.io (a platform that can be summarized as "Android for your personal server").
Android was in fact meant to work this way, with apps providing such functionality through intent filters that match the PICK or GET_CONTENT actions.
But Android is also supposed to work through ContentProvider components that enable access to databases. Sometimes you need more than a PICK action performed by an external app. As in the case when you want to make an alternate implementation of a contact picker.
This is why the issue has to be addressed directly, by making many if not all permissions optional, and settable per app. Handling a SecurityException is not burdensome. Much of the permission overreach is due to crappy "behavioral targeting" data collection that doesn't really work. Nobody will miss it.
Android does have an API to do that, and as far as I know it's always had this ability. The problem is that developers aren't interested in using it. The stock contact picker can mess with an app's "flow" and it might not match the overall design of the app. Developers would rather implement their own contact picker than use the one the OS provides, and that requires permission to read all contact data.
1) The Android UI designers need to get on it and figure out how to make the contact picker more acceptable to developers. This could involve adding some flags that adjust the look and feel. But keep in mind that Android apps are all supposed to be following common design guidelines anyway, so apps shouldn't be excessively customizing common elements.
2) Don't let apps request access to all contacts in the first place. Don't give them any choice except to use the picker. Obviously it's far too late for this now, but if it had been done this way in the beginning, then there would actually be pressure to make the system picker work acceptably.
Take contact lists as an example.
Many programs request access to your contact list. Usually, this is so that they can display back to you a contact picker that lets you choose some set of contents which you want to share with, or otherwise invite to use the app. A few bad apps will just spam your contacts without your approval.
How could we make this more secure? Well, imagine that Android itself implemented a contact picker API. Instead of requesting access to contacts upfront, a program would call an API to say "Please ask the user to select some contacts for purpose X". The platform itself would then render a contact picker UI, and the user would pick some contacts. Only the chosen contacts would be returned to the app.
As far as the user is concerned, for legitimate apps, the UX I described is exactly the same as what they get now, except that the app doesn't have to request general access to the user's contact list upfront, and thus the whole thing is more secure. It's strictly superior! And this approach -- of inferring security from decisions the user is making anyway, by making those decisions happen in privileged UIs rendered by the platform -- turns out to extend to far more than just contacts.
This is the model I'm currently implementing in https://sandstorm.io (a platform that can be summarized as "Android for your personal server").