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.
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)
> 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.
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".
That's the most baffling thing to me. There is simply no option to remove network permissions from any app on my Pixel phone.
It's one of the reasons why I avoid using mobile apps whenever I can.
I believe that would theoretically allow exfiltration of data but I don't understand all of the details behind this behavior and how far it goes.
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.
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.
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.
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.
Did you find a suitable app? I don't really remember, but https://play.google.com/store/apps/details?id=com.nxp.taginf... might suit you.
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.
E.g. TrackerControl https://github.com/TrackerControl/tracker-control-android can do it, it is a local vpn which sees which application is making a request and blocks it.
You can write your own version of it if you don't trust them.
And neither Android nor iOS a safer than modern Desktop systems. On the contrary because leaking data is its own security issue.
https://securityonline.info/androids-secret-tracking-meta-ya...
Search string for DDG: Meta proxy localhost data exfiltration
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.
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.
...in the absence of sandbox escape bugs.