> Give the old gallery app fake file access, making it completely useless?
Yes. When any API is used for the first time, pop up a toast saying "this legacy app is trying to use File Access permissions. [Allow access to whole device] / [ Restrict to apps own files ]".
If the user hits 'allow', grant the legacy API. If the user hits 'restrict', give a fake filesystem.
The dialogue box should be provided by the OS, and if the threading model doesn't allow pausing the app to wait for user interaction, simply kill the app to ask the question, and restart it with the permission.
Except that legacy app owners regularly get offered money by bad actors, to purchase the apps and take over. Which means that anyone who "Allow access to whole device" suddenly gets a malicious update that cryptolocks them or steals their files.
Real scenario, real problem, semi-common attack vector. Enough that it's a serious problem for Google.
You don't have to give access to whole device. Ask the user what he wants to share, then present the app with a skeleton directory tree where only allowed parts are visible. App can as well think that is has a "full access" whatever that means, it's a matter of terminology.
You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.
The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.
> You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.
No. It knows which actual paths the app tries to access. They can be grouped into exactly the same permission bundles (access to camera images, access to downloads etc) which are used for newer apps. Then presented to the user for approval, like they are with newer apps.
The only difference is, you may not get all permission popups at once -- but that's already the case with many newer apps. They only ask for permissions to e.g use camera when you actually need it. And I like it so much better than the old approach when the apps would refuse to run without camera even though I don't need this particular feature.
> The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.
Right, and exactly the same problem applies to new apps natively built against the new API. The app can request unreasonably wide permissions and the user will make the damn popup go away. It's not relevant to the problem of maintenance of old apps.
Yes. When any API is used for the first time, pop up a toast saying "this legacy app is trying to use File Access permissions. [Allow access to whole device] / [ Restrict to apps own files ]".
If the user hits 'allow', grant the legacy API. If the user hits 'restrict', give a fake filesystem.
The dialogue box should be provided by the OS, and if the threading model doesn't allow pausing the app to wait for user interaction, simply kill the app to ask the question, and restart it with the permission.