> with of course the issue that developers can simply lie

And not something that should be hand waved away in the quest to say that written descriptions are better. They are not, but having both in other can help to a great extent. A practice I've rarely seen is the description containing each permission name, and what it's needed for, in other words, explaining that mapping that's missing.

>Other permissions like ACCESS_FINE_LOCATION being required until recently for accessing Bluetooth devices meant that users would think that every BLE app was spying on them.

This was a dumb hack by Google. "BLE can be used to spy on your location" => "you must grant all location data to said app".

This is something that is better dealt with a clear privacy warning next to the actually relevant permission rather than conflating it with GPS.

And of course what users generally really care about is "does this app upload my location to somewhere? continuously or only when I take a specific action?" but permissions of that type are basically impossible to enforce by technical measures.

I care about risks. The problem is that when the risks are complicated and google tries to dumb it down or hide information to simplify it they inadvertently make it more complicated and stupid at the same time.

I'd rather they just put all the information out there on full display and maybe create an API that lets apps compete over explaining it clearly/warning users.

Yes, because they can lie, and because given how the Play store operates, Google is probably going to be worse than Apple at detecting lies, it’s nice to see permissions because they function as an upper bound on the extent of the lie. And while there are issues with using permissions for this because they are not always easy to interpret, they often are, so the benefit is clear.

I want the programmatically generated list of permissions. I want those permissions to be more granular, not less. I want the developer to explain why they're using each permission.