Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How can the new API know this?

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_.

This stuff is highly non-trivial.



> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: