[simonsarris]

That seems OK since it still asks you as it needs them when running an app, and "prunes" permissions away from apps that you do not use often.

Lots of apps only need specific permissions if you use specific parts of the app. And apps are much larger (one app does more things) than they were 5-10 years ago. Eg you can use some apps as a camera, but never as a photo editor, and get use out of it by only giving some specific permissions (camera), forever.

[Dig1t]

You are right, but that doesn't seem like a good excuse to remove that information from the Play Store completely. It would be trivial for the Android APIs to require that all permissions requested programmatically are also present in the manifest. This would continue to give user's a picture of what the app could/would request.

They could just change their play store listing from "Required permissions" to "Permissions this app can request". This is similar to the "nutrition label" approach that the Apple App Store has.

[djbusby]

IIRC it's already in the manifest.

[abeyer]

Yup, you must _both_ put the perms in your manifest, and then _also_ request them at runtime now (at least for many "sensitive" ones... not sure if there are exceptions for any others.)

Google's docs are very clear that apps are meant to explain the need for perms, and the impact of denying them at runtime... I'd love to see the play store to also provide publishers a way to specify what the impact/loss of features is if you deny them at runtime. Trustworthy publishers would love this, and the non-trustworthy ones... ¯\_(ツ)_/¯

[thaumasiotes]

> That seems OK since it still asks you as it needs them when running an app, and "prunes" permissions away from apps that you do not use often.

No no no no no, this is a total catastrophe. I can't understand how it got implemented at all.

I just missed a birthday notification from my calendar app because Android "helpfully" removed the app's ability to create notifications! After all, I hadn't opened the calendar app in more than six months!

Infuriatingly, I caught the original message telling me "hey, we just noticed that your calendar shouldn't be allowed to send you reminders" and I tried to restore the permission, but that doesn't seem to have worked.

Whoever designed and implemented this "feature" shouldn't be trusted to put on pants.

[mdp2021]

> and "prunes" permissions away from apps that you do not use often

Certainly agreed: a system should never "take the initiative" and replace you in decisions.

I am seeing cars that act along the lines of "Ah, you turned off the air conditioning, so I'll proactively open the windows": this clearly indicates that some manufacturers have embraced decadence and nihilism, they "have given up" and "want to watch the world burn" (unless they are simply underage savages).

[jfim]

Yeah that feature is complete garbage. The intent is laudable (reducing permissions for unused apps) but the implementation of getting a notification every once in a while with a ton of permissions removed is awful.

Combined with the fact that Google seems to be sending more notifications for all kinds of junk nowadays makes it even easier to fail to notice that.

[nybble41]

Fully agreed. What's worse, even if you painstakingly go through all your apps and disable this anti-feature—since there no global setting—it just gets turned back on the next time the app is updated. Putting aside the abysmal UX, automated systems should respect clearly-expressed user preferences.

[lupire]

Android documentation says that if the permission is auto removed, you'll get a permission prompt next time a notification is sent.

[is_true]

This clearly isn't OK. I want to choose between an app that asks for what it needs to work and an app that ask everything it can, before installing it. It's a dark pattern.

[ece]

The new data safety section lists things that look like permissions as well. Should permissions be clearly listed in the new data safety section? I think it would be more helpful that way.

[bagacrap]

Don't you have more context to understand and grant the permission request at runtime? For example a banking app might want access to the camera for depositing checks, but until I'm actually depositing a check it might not be clear why it would want to use the camera.

[is_true]

You can ask later, too. But be clear upfront, I want to compare choices. Not many choices in that case in which you install the app your banks has.

[morder]

I'd prefer to avoid even downloading apps if they ask for permissions that aren't necessary. To hide that just makes me never want to use the play story anymore.

[lostgame]

Why is this okay?

I wouldn’t download, e.g.; a video game that would ask for my contacts or location.

Why should I have to download and wait for the app to install before I know what permissions it’s asking for?

Furthermore - what’s the possible purpose of removing this information when it was already there?

[lupire]

Here's a reason: if you never download it, you can't give it a 1-star review.

[uranium]

One of the permissions I'm really reluctant to grant is "run at startup". As far as I know, that's granted at install time, not prompted for, and there's no way to disallow it. Is there now going to be no way to know if I'm granting that or not?

[lupire]

What's wrong with run at startup?

[flaviut]

My calculator doesn't need to run at startup. There's nothing useful it could do in that situation, the only possible reason is to download ads, track me, or just pointlessly waste battery.

Ditto for a wide range of apps. Pretty much everything that isn't a messaging app.

[uranium]

Exactly. Tracking me, wasting my resources, etc.

[datalist]

What about standard permissions? The user is never prompted for them.

[dotancohen]

What are standard permissions in this context?

[codethief]

Network access, for example

[retox]

This change was when I stopped downloading from the Play store. Prior to that you could easily see that the compass or flashlight app you were going to install needed network access, something that set off alarm bells given the state of malware back then.

[Gigachad]

It was a bit of a pointless permission because literally every app requested it. The android permissions system very quickly fatigued users in to accepting everything. The new model is much better. Allow the user to actually deny the important permissions but just accept that network access is what apps do now.

[mdp2021]

> literally every app requested it

No, not every application requested network access. And surely not a small number of users checked if a calculator or a sound recorder did, and, also checking the developers' justifications for including specific permissions, decided their (dis)trust.

[rrrrrrrrrrrryan]

I agree this is a better set of defaults, but there should be a toggle in the settings someplace, even deep in the developer mode settings, that gives users control over more granular permissions and allows them to choose which permissions to auto-grant and/or auto-deny.

[mdp2021]

Since when network access is standard? Access to filesystem is not, use of hardware components but for display and speaker is not, internet access is not... Maybe you are referring to the exploitation of "intents" to exchange with networking enabled applications?

[kuschku]

Network access requires no user approval. The only place you could find it before granting it to an app was via the permissions list in the play store.

[mdp2021]

Ok, let us clarify the matter a little.

An Android application requires "permissions" to do "anything past the basics"; permissions have to be declared in the "Manifest" file.

There are (simplifying) two main types of permissions: "normal"¹ and "dangerous, runtime"²; the former only need to be specified by the programmer in the Manifest; the latter also need direct confirmation from the user at a requester prompt.

This implies that "normal" permissions are granted by the user implicitly with the action of installing the application. Which means, that it is _quite important_ that the user sees the permissions list beforehand, before installation.

--

¹"Normal": BLUETOOTH, INTERNET, VIBRATE...

²"Dangerous": READ_CONTACTS, RECORD_AUDIO, SEND_SMS...

[uranium]

Same with "run at startup" and some other important ones; there's no way to deny it once installed.