The thing is, that Android permissions don't really map to user privacy in a way that's useful, and definitely not in a way that makes sense to users; simply listing them is actively misleading.
For example, every app gets INTERNET by default, meaning that lots of privacy-violating things don't have to be declared at all! 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. People don't understand the implications of what a permission means for their data / privacy
A developer-written description of exactly what an app is doing with user data and why is much better (with of course the issue that developers can simply lie)
> 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.
At this point I'm cynical of it all... Any conduct promisses by modern device and app makers is worth a pilar of salt after the constant breeches of trust by them.
A lot of security settings (especially on the privacy level) are often too over-complex or total placebo in nature. A big problem is that these settings often get wiped and unstick themselves every time an app or OS update occurs, which totally defeats the purpose of having to configure apps independently. Many apps like TikTok and Instagram barely even function unless you grant them invasive camera and microphone access regularly (not even selectively).
Regulators need to pursue device makers instead of trying to address each individual app maker... Samsung and Apple grant access to accelerometers, cameras, contacts, etc. to begin with to apps (even when it's nowhere necessary), rather than just restricting access at the device and OS level... This allows device makers to grant certain apps backdoors for a fee.
Modern phones make me miss Blackberries so much, it's a damn shame they're barely compatible with modern networks now or I'd light my old one up and forget about these overpriced touch screen snitch/spy devices.
As with many inexplicable decisions that come from many large companies: it's what happens when teams make decisions in a vacuum chamber maintained inside a bubble held inside an ivory tower surrounded by a silo. I exaggerate but the teams will not always be in touch with The external feedback often comes as a surprise and if they care, they will scramble for a response.
No question that Google has just been trying to ape Apple lately, but for mobile specifically there are actually lots of features that android and its ecosystem had for years before Apple finally added (copied) it for iOS.
With permissions, before Google started to copy Apple's system, there was no such thing as an Android user being able to deny an app permission to do something. Either you gave the app permission to do everything it wanted, or you couldn't install the app at all.
Isn't the next version of Android the first time users will be allowed to deny an app permission to send notifications? That's been in iOS from the start and has always provided a way to silence apps that spam notifications.
Android has had the ability to turn off notifications since Android 4.1 (July of 2012) and I'm pretty sure the ability to turn off notifications on iOS was added in iOS 5 (October 2011)
iOS only added permissions at all in iOS 6, before that apps had access to photos, calendars, contacts and reminders automatically.
>One of the most notable changes in Android 13 is the new runtime permission model for notifications. In previous Android versions, apps could post notifications by default without requesting any permission.
Yes, notification permission was previously granted by default, because the ability to block an app from sending notifications predates the concept of affirmative app "permissions".
Android has recently been refining their notifications model, increasing the granularity of the notifications by splitting them into "types" and user-assigned "priority" levels. It seems default-off is the newest step in that, apparently.
>Android 13 (API level 33) introduces a new runtime permission for sending non-exempt notifications from an app: POST_NOTIFICATIONS. This change helps users focus on the notifications that are most important to them.
Entitlements aren't permissions. There are a lot of operating system services which are privacy-relevant, but which don't have associated entitlements (e.g. location services or contacts access), and a lot of entitlements that aren't related to permissions (like ones that let an application request an increased memory limit, or allow it to store data in iCloud).
Here's a full list of entitlements from Apple. You'll find that a lot of them wouldn't make sense to display on a store page:
Never. But they have “privacy nutrition labels” that show what data is tracked either anonymously or linked to you. It’s quite helpful, and likely easier to read than a raw list of permissions.
When I saw this post I assumed Google was rolling back their privacy nutrition label like things they added. I didn’t realize it was about the granular list.
> The Data safety section provides users with a simplified view of how an app collects, shares, & secures user data, but we also want to make app permissions information easily viewable ...
^ are these vetted in any way? are they enforced? I'm okay with this being 'vendor says this', but if app stores are reporting it next to permissions (which are programmatic constraints), feels like it's at best aspirational, potentially deceptive. Are there real penalties? Or is this just a system for wrist slapping in the rare case someone is caught in a lie.
> When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action.
There are at least some checks in place. I was filling it out for an app that I work on, and forgot about a feature where we shared a GPS location with an API to get a street address. I checked the box to say that the users GPS position never leaves the phone and I pretty much instantly got an email saying that the app was rejected and to fill out the form again.
That's good to hear, but how do they tell? I mean, following a GPS API call through to something that talks over the network seems like the kind of thing that would be a decent amount of work even with the source code; am I underestimating the state of modern analysis on binaries?
