There's a balancing act. Historically Android would just provide a list of what permissions each app wants, and you either take it or leave it. That's transparent in a sense, if researchers care they can do the analysis and produce a paper, "Hey, 80% of the top X apps request permission Y which they have no Earthly reason to need" - but almost no end users will read this boring technical stuff to make decisions. See also pre-Baseline Requirements "class based" X.509 certificates. Adding more permissions to this list is easy... but also has almost no effect. There's a good chance you've never looked at the permissions you granted most apps you have.
In the modern era some of these abilities also require an explicit grant of permission when used. Location is an example we've all seen.
But that incurs fatigue so it has to be used cautiously. For example Android could ask if apps are allowed to use the Network, but you'd likely get sick of that really quickly, so instead you can explicitly disable network access for an app if you want, but it doesn't ask "Can Daily-quiz-app-1234 access the network?" when you run it.
One option Google has that's more extreme than a fatigue-inducing prompt, is to just refuse permission anyway, which is what's happening here.
And unlike iOS, an Android phone can run other browsers, but for a modern browser on a nice phone you want WebAuthn. If any app can just say "I'm actually a web browser" then WebAuthn's phishing protection blows away when you install some Flappy Bird clone to try it out - the app just tells the OS it's a web browser, comes up with some excuse as to why you should touch your fingerprint sensor, and it says to the OS it's browsing https://your-bank.example/ so it gets credentials for your bank. So in this case Google manages some high risk permissions only for known safe developers. Mozilla's public Firefox builds have this "I'm really a web browser, I get to do WebAuthn" permission, but if you build the exact same source and sideload it, it can't do WebAuthn.
[Apps all get the same, likewise unphishable, feature on capable phones, Android or iOS, but without this "web browser" permission it's fixed so that they can't ask for credentials for a web site, only for their own app]
> There's a balancing act. Historically Android would just provide a list of what permissions each app wants
That's one of the many design choices that made truly filthy apps possible on Android. I worked on a device monitoring(wink) app back in the day(which I'm not proud of). The things we did there...Installing apps without an app store, hiding application icon(!), recording phone calls(!!!), reading messages(!!!). And all of that was done using official APIs on a non-rooted device.
Permissions are something I wish desktop os’s would adopt. In most systems, any rando application I run has access to every computer resource that I as a user have access too! Depending on the system, this could mean: my personal documents, my desktop folder, my downloads, all attached peripherals, including microphones and cameras, serial and parallel ports, any radios including WiFi and Bluetooth, the network, a list of running processes, a list of installed applications, the clipboard, and on and on. Why on earth should this be the default? As a user, I should be able to easily deny any application access to these things.
This made a little sense when you could trust application developers with access to all these things, but that ship has long since sailed.
Why would access to the fingerprint sensor give the ability to forge WebAuthn signatures? An app being able to detect that the phone’s user has their finger on the sensor does not in any way compromise the security of a different app doing the same thing.
Obviously one could write a malicious browser that implements WebAuthn wrong and compromises users who register with a site using that browser. This leads to discussions about WebAuthn attestation, and there are valid arguments there both ways.
> Why would access to the fingerprint sensor give the ability to forge WebAuthn signatures?
It wouldn't? No apps get access to the fingerprint sensor, it's very hard to imagine any legitimate purpose for that, and easy to imagine hostile use cases.
The operating system doesn't give access to the fingerprint sensor, it provides an API for doing FIDO (the underlying technology to deliver WebAuthn) and the fingerprint sensor is used by the operating system to provide User Verification for that.
The API takes a parameter for the Relying Party Identifier. For most phone apps, you can't control this, it'll be set to an ID for your app, which you can discover and fill out in your server backend. This way your app can authenticate your users to your servers, but other apps can't imitate it.
But for WebAuthn the RPID is based on the DNS name of the web site, so a web browser needs a way to actually set this value or it can't do WebAuthn. Hence, Android needs an extra permission flag to authorise legitimate web browsers to set the RPID while preventing untrustworthy apps from doing so.
This sounds like a mediocre design. An entirely separate key hierarchy per app would avoid any possibility of confusion signatures with those generated by another app, even if both apps were web browsers.
> so instead you can explicitly disable network access for an app if you want
Some OEMs provide this feature in their firmware, but many/most do not. Users have to resort to running local VPNs like NetGuard. Even ADB can't do it: "Permission android.permission.INTERNET requested by com.android.vending is not a changeable permission type". If you know a way, please share!
I understand permission fatigue but this lack of control is, to me, blatantly user-hostile.
"Google is limiting what apps can use the QUERY_ALL_PACKAGES permission that “gives visibility into the inventory of installed apps on a given device.” "
Sounds like it already is. Google Play is simply changing its policy on which apps may request that permission.
Because that capability is required for apps to interoperate. Sandboxing by definition breaks the ability for apps to share data and work together. It's a balance to be struck, a perfectly secure system is a useless system.
In this case it was mostly used to render custom share dialogs (you need to list apps for that), in-line share buttons (checking if other app exists is useful to not show the ones that aren't installed) and some other possible optimizations (e.g. mostly bug fixes for broken apps that couldn't handle types of data).
From developers perspective it's useful because it makes your app more reliable and easy to use. With the downside that malicious people can abuse it.
I see absolutely no reason for this. You want to share a picture? Fine! Just specify a content type, and the system will present a list of apps capable of handling it to the user.
Sharing pictures isn't the only use case. The APIs were widely used for quite a few other use-cases as well (this is why it's a permission now and not removed completely).
Please remember that but everyone subscribes to your exact model of safety and capability. There are people that want more from their pocket computers than a restricted consumer device.
IMO internet access (android.permission.INTERNET) needs to be a runtime permission. Ideally with the same kind of granularity as location — one time, while app is in use, in the background (through settings). And give an app a brief window to access the internet after an FCM push, but FCM pushes are also a runtime permission.
But Google being an advertising company would, of course, never ever do this.
This means that nearly every application will have a pop up which nearly every user will get so used to seeing that they'll almost always just press "allow" on, which will mean permission prompts become less useful and security gets worse.
IIRC part of the problem is that there are other leaks through the intent system. So the system is so broken that adding a permission for INTERNET would just be an illusion of safety.
What do you mean? If you don't have the INTERNET permission in your manifest, you won't be able to create network sockets. So this enforcement is already in place, it has always been. The only possibility I see of leaking internet access through the intent system is when an app that does have internet access would give content:// URIs with granted URI permissions to an app that does not, so it would indirectly and unknowingly download something from the internet through that app's content provider. I don't think it's possible to grant anything on an http(s) URI. For that matter, almost any permission can be "leaked" this way. You could even skip the intents and content providers and just do it with straight AIDL if you're so inclined.
Android's permission system is pretty solid and almost impossible to work around.
The point of removing the INTERNET permission as I see it is to prevent the app from sending out any information, allowing you to trust it with your sensitive information. However if the app can raise an intent that will cause another app to send out information of its choosing it has effectively broken that permission, even if it never created a socket. Sure, the app may have a hard time getting information back (although there are channels such as app updates at the very least) it isn't enough to trust an app with your passwords just because it doesn't have any permissions.
Matter of fact, why aren't a lot more abilities behind permissions?