If an app updates to require new permissions, or to suddenly require network access, or the owner contact details change, Google Play should ideally stop that during the update review process and let the users know. But that wouldn't be good for business.
An update can become malicious even without change in permissions.
E.g. my now perfectly fine QR reader already has access to camera (obvious), media (to read QR in an image file or photo) and network (enhanced security by on-demand checking the URL for me and showing OG etc so I can more informed choose to open the URL)
But it could now start sending all my photo's to train an LLM or secretly make pictures of the inside of my home, or start mining crypto or whatnot. Without me noticing.
See that's what the intent system was originally designed to prevent.
Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
Similarly for the camera.
And in fact, it should have no network access whatsoever (and network should be a user controllable permission, as it used to be — the only reason that was removed is that people would block network access to block ads)
> And in fact, it should have no network access whatsoever (and network should be a user controllable permission, as it used to be — the only reason that was removed is that people would block network access to block ads)
Sure, a QR code scanner can work fine without network.
E.g. it could use the network to check a scanned URL against the "safe browsing API" or to pre-fetch the URL and show me a nice OG preview. You are correct to say you may not need nor want this. But I and others may like such features.
Point is not to discuss wether a QR scanner should have network-access, but to say that once a permission is there for obvious or correct reasons, it can in future easily get abused for other reasons. Without changing the permissions.
My mail-app needs network. Nothing prohibits it from abusing this after an update to pull in ads, or send telemetry to third parties. My sound record app needs microphone permissions. Nothing prohibits it from "secretly" recording my conversations after an update (detectable since a LED and icon will light up).
If you want to solve "app becoming malicious after an update", permissions aren't the tool. They are a tiny piece of that puzzle, but "better permissions" aren't the solution either. Nor is "better awareness of permissions by users".
> See that's what the intent system was originally designed to prevent.
> Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
On the one hand, yes, good point, but it runs into the usual problem with strict sandboxing – it works for the simple default use case, but as soon as you want to do more advanced stuff, offer a nicer UI, etc. etc. it breaks down.
E.g. barcode scanners – yes, technically you could send a media capture intent to ask the camera app to capture a single photo without needing the camera permission yourself, but then you run into the problem that maybe the photo isn't suitable enough for successful barcode detection, so you have to ask the user to take another picture, and perhaps another, and another, and…
So much nicer to request the camera permission after all and then capture a live image stream and automatically re-run the detection algorithm until a code has been found.
The network permission was displayed in the first versions of Android, then removed. I heard (hearsay alert) at the time that it was because so many apps needed it, and they wanted to get rid of always-yes questions. IIRC this happened before the rise of in-app advertising.
If people always answer yes, they grow tired and eventually don't notice the question. I've seen it happen with "do you want to overwrite the previous version of the document you're editing, which you saved two minutes ago?" At that point your question is just poisoning the well. Makes sense, but still, hearsay alert.
As far as I'm concerned they can grant this permission by default. I just want the power to disable it.
A while ago I wanted to scan the NFC chip in my passport. Obviously, I didn't want this information to leave my device.
There are many small utility apps and games that have no reason to require network access. So "need" is not quite the right word here. They _want_ network access and they _want_ to be able to bully users into granting it.
That's a weird justification for granting it by default. But I wouldn't care if I could disable it.
Android doesn't grant this by default, strictly speaking. Rather, an application can enable it by listing it in the application manifest. Most permissions require a question to to the user.
Well, the original intent was to ask the user for permission at installation time, which turned out to be a poor idea after a while. Perhaps you mean that it would have been simple to change the API in some particular way, while retaining compatibility with existing apps? If I remember the timeline correctly, which is far from certain, this happened around the same time as Android passed 100k apps, so a fairly strong compatibility requirement.
I mean, just make it "Granted" by default and give user ability to control it. Permissions API was already broken few times(i.e. Location for bluetooth and granular Files permissions)
> Does Google refuse to veriy their firmware if they offer this feature?
If a manufacturer doesn't follow the Android CDD (https://source.android.com/docs/compatibility/cdd), Google will not allow them to bundle Google's closed source apps (which include the Google Play store). It was originally a measure to prevent fragmentation. I don't know whether this particular detail (not exposing this particular permission) is part of the CDD.
It's not explicitly part of the CDD, but implicitly. The device must support the Android permissions model and is only allowed to extend this implementation using OWN permissions (in a different namespace than 'android'), but not allowed to deviate from it.
INTERNET is a "normal permission", automatically granted at install time if declared in the manifest.
OEMs cannot change the grant behavior without breaking compatibility because:
The CDD explicitly states that the Android security model must remain intact.
Any deviation would fail CTS (Compatibility Test Suite) and prevent Play certification.
Well, apart from the OEM violating the Android Compatibility Definition Document (CDD), failing the Compatibility Test Suite (CTS) and thus not getting their device Play-certified (so not being able to preload all the Google services, there is an economical impact as well:
As OEM you want Carriers to sell your device above everything else, because they are able to sell large volumes.
Carriers make money using network traffic, Google is paying Revenue-Share for ads to Carriers (and OEMs of certain size). Carriers measure this as part of the average revenue per user (ARPU).
--> The device would be designed to create less ARPU for the Carrier and Google and thus be less attractive for the entire ecosystem.
I've been using a similar VPN solution. It works great for apps that absolutely should not be connected, like my keyboard. But it has an obvious downside: you can't use a VPN on your phone while you're using that.
Some apps would use this for loopback addresses, which as far as I know will then need network permission. The problem here is the permission system itself because ironically Google Play is full of malicious software.
And neither Android nor iOS a safer than modern Desktop systems. On the contrary because leaking data is its own security issue.
Yes. Facebook/Meta was using a locally hosted proxy to get info smuggled back without using routes that are increasingly obstructed by things like ad blockers if I recall correctly.
This is a huge problem in the Chrome Web Store and Google is doing very little about it. If you ever made an extension that is even just a little popular, expect to get acquisition offers by people who want to add malicious features somewhere between click fraud, residential IP services or even password stealers.
Same for Play Store. I have 2 games and I keep getting offers all the time. The last one offered $2000 for the developer account or a $100 monthly rent.
From their email pitch:
> We’re now offering from $500 to $2000 for a one-time purchase of a developer account that includes apps, or a rental deal starting from $100.
> No hidden conditions — quick process, secure agreement, and immediate payment upon verification.
> We’re simply looking for reliable accounts to publish our client apps quickly, and yours could be a perfect match.
Indeed, an update can't be more malicious than the permissions allow it to be. You have a calculator app with limited permissions, it is "safe" to set to allow the developer to update it. No danger in that.
But I don't think it is enough, or it is the right model. In other cases, when the app has dangerous permissions already, auto-update should be a no-go.
