[josephcsible]

This feels like treating one particularly visible symptom of the problem instead of fixing the actual problem. What Google should do instead is prevent apps from refusing to work or disabling unrelated functionality just because some permissions are denied (e.g., if you deny your banking app permission to access your camera, everything but mobile check deposit should still have to work). They should use a two-pronged approach to do so:

1. Make that a rule in the Play Store and ban apps that violate it

2. Make Android present convincing fake data to apps when permissions are denied

[hakre]

Additionally there should be a sandbox mode. While you give the app access to Photos and Contacts, it's an actual sandbox not containing any photo nor any contact. So the app gets what it asks for (the permission) while the user can still control the data.

[charrondev]

This is how photos access on iOS works. An app can ask for access to photos and you can choose 3 options:

- no photos - only specific photos (the system picker will appear to select them) - all photos

[patch_cable]

Regretfully, it seems on iOS apps can tell they’ve been given access to only specific photos. Googles Photo app refuses to work unless it gets access to all photos.

[actionablefiber]

WeChat will loudly grumble every time you try to send a photo if you haven't given access to all photos. But at least it works.

[hakre]

And if you tell me now, that it works without having access to contacts, its lightyears ahead of WhatsApp.

But still, these moaning dialogs aren't trust-building. I wish there would be better guidance with UX in the industry.

[throwaway290]

WhatsApp works without access to contacts now, no?

[mrbungie]

I think it's a good design decision that just lacks control during the app review process.

There are apps that need full access to your photo gallery to be really useful (i.e. where limited pool of photos may have little sense in those contexts), photo deduplication apps being a case on point. At least that piece of information gives the app a chance to tell the user that it may not work as expected.

Now, if an app misbehaves based on photo sharing permissions (i.e. Google Photos not being able to work), that is a decision that the product team took. They're the ones responsible and that should be judged.

If anything there should be tighter controls during the app review process on how those apps use that info and avoid the ones that only work when sharing the full gallery.

[never_inline]

I am the user, and if I allow only Screenshot and Whatsapp images folder to be accessed by your deduplication app, I want it to work on these 2 folders only, without accessing my camera. Same for lets say backup app.

[mrbungie]

Yeah sure, that's what should happen. I'm not saying otherwise, read the comment again.

[hakre]

YMMV, but IMHO it is preferable that the fundamental execution model of the app stays in control of the app-executing user and should not be affected or be dependent on the app review process. Rationale is to prevent single point of failures, especially those that are out of control of the user (compare with the emergency off switch on some bigger machinery).

[smileybarry]

This was an annoying issue with one of the Twitter competitors a while ago; their app asked for photo access, I gave it partial access, it grumbled that it needs ALL of it, and refused to let me upload any photo. I thought it was a "total photos < X" heuristic, so I went back and picked like 30 old photos, and it still knew that wasn't all of it.

[GoblinSlayer]

Probably because it's file based. Don't they have a feature to paste a picture from clipboard or photocamera?

[smileybarry]

That still works regardless of file permissions, own-app storage is always allowed on both iOS and Android since ever on iOS and since Android ~6. And clipboard access is all API-based, at least.

[ShamelessC]

What is regretful about that?

[SilasX]

That was a change that seemed to add inconvenience but no additional security. Now I have to first approve an individual photo, then search the pre-approved photos for the photo I just added (they will be sorted by time). Why can't they just let me approve and add a photo at the same time?

[gleenn]

But it absolutely provides more security... the app can see only the exact photos you allow. It is a bit annoying as an extra step, but I'll happily give apps access to a single photo selectively versus the all-or-nothing approach where I might choose to completely stop using an app.

[SilasX]

Sorry, yes, the segmenting out of permissions on a per-picture basis adds security. What I mean is, the additional hassle added, but the way iOS and apps currently do it, is not necessary for that security. There should be an interface directly from the prompt for pictures on the app's side, to the selection of photo's on my phone's side, to the point that adding pictures is just as easy as it was before. There's no reason for the extra steps to get this added security.

[Operyl]

You can unselect all from the dialog every time, iirc, as a work around for this.

[KORraN]

I'm not sure, if it works as advertised. I've been playing with one of the apps and despite selecting "No photos" option, I was still able to upload photos from my gallery. Perhaps some metadata is not shared in this case, but photos definitely were accessible.

[blokey]

There are two APIs in iOS for the photo browser, the API where the app gets access to your photos so it can draw the list view of “all the pictures” is gated with the permission.

The newer API that pops up a system control that lets you select a photo (or more) and only then if you select one, it returns that picture (only) to the application, that API does not need permission, because unless you select a photo, the app does not have access to anything.

[KORraN]

Yes, you are right, thank you. After I have posted my comment, I started reading about PHPickerViewController and it totally makes sense.

[copper-float]

GrapheneOS supports this with a feature called Storage Scopes. Instead of giving an app access to your entire photo library and files, you can limit its scope to an individual folder of your choice.

That way the app still gets the permissions it asked for, but they're specifically what you want it to see.

[hakre]

> GrapheneOS supports this with a feature called Storage Scopes

Thanks for the pointer, adding the missing reference: https://grapheneos.org/features#storage-scopes

This looks pretty interesting (and there's more GrapheneOS has to offer):

> GrapheneOS provides Storage Scopes as a fully compatible alternative to the standard Android storage permissions. Instead of granting storage permissions, users can enable Storage Scopes to make the app assume that it has all storage permissions that it asked for. On Android, an app that doesn't have any storage permissions is still allowed to create files and directories, and is allowed to access the files that it created. Users can optionally add files and directories as storage scopes to permit the app to access files created by other apps.

This comes pretty close to what I imagined, thanks a lot for providing this living example!

[theptip]

This is the obvious solution, it’s really annoying that it is not available for every permission. (Contacts is the big missing one in iOS, but you could even have a fake GPS that returns random positions.)

[IceWreck]

LineageOS used to patch this on top of android afew years ago, not sure if its still there.

[marissachan]

"2. Make Android present convincing fake data to apps when permissions are denied"

This is actually a feature with MIUI, though I am not sure if this is part of the global release or only Xiaomi.eu, a modified version of the chinese release). https://xiaomi.eu/community/attachments/screenshot_2022-10-2...

[riedel]

This is cool, why is that not a wider available feature in custom ROMs particularly. I used XPrivacy with xposed some time ago to inject that functionality. It was even possible to only expose randomised or fixed GPS and an excerpt from the address book (only favourites).

[celdon25]

The actual problem is that travesties of this scale are allowed to happen on Google’s watch for so long, despite the Orwellian grip it has on deciding what apps are allowed to be listed. A good example of why that system needs to be reformed.

This particular issue didn’t get addressed until at least 8 months after TechCrunch exposed the practice. Where was Google?

Control of the App Store and Play Stores should be carefully transferred to an independent organization, with an open governance model and a mission to serve consumer interests. It won’t be perfect but it would be a big step up.

If that can’t be done for whatever reason, find another way to disrupt the App Store. I struggle to think of why not doing so is a net good for society.

[waselighis]

> 2. Make Android present convincing fake data to apps when permissions are denied

That reminds me, years ago I used to run a module called XPrivacy that does exactly this. It does require a rooted Android device though. I haven't used it for a long time, but seems it continues to live on as XPrivacyLua.

[aceazzameen]

I used to use that too. It was great! I haven't run a rooted device in like 8 years though. These days I don't bother installing most apps on my devices anymore. I mainly use the phone, messaging, camera, and Firefox. And I use Netguard to block the uninstall-able apps from internet access.

[supriyo-biswas]

That approach would leave users confused as they see fake contacts or photos being surfaced through the app that was denied said permissions.

[asddubs]

it should just present an empty list, like a newly installed phone with no pictures taken yet / no contacts added. if apps detect that and refuse to function, ban them from the app store

[waboremo]

Only if you use fake contacts and photos that look real. Instead whenever this is done elsewhere, there is text on the image and the names are obvious. Google can even add a page within privacy where you see the fake options before you can enable it system-wide/per-app.

[supriyo-biswas]

The app could also detect the fake text based on general testing (after all, there's gonna be only so many variations of "Biggus Dickus") and refuse to dispense the functionality in question.

[fbdab103]

Hence the suggested rule that blocking functionality based on this access should be an app store violation.

[joshuaissac]

The OS could add an option to automatically generate realistic mock data. It could be tuned based on the distribution of names in the location that is revealed to the app (whether that is the real location or a mocked one).

[amelius]

I wrote almost exactly this comment more than five years ago. It is a shame that it is taking them so long to get security right. Do they even use their own software?

[rblatz]

I don’t have much faith in Google for doing that. The Google Photo app only works on iOS if you allow it access to the iOS photo library. I wanted to use it to access photos shared with me, or otherwise stored in Google Photos, not to give google access to all the photos on my phone.

[prepend]

It’s pretty funny that Google has this rule and then slurps up all data for their own purposes and there’s no way to opt out on android if you use the google distro.

[2Gkashmiri]

Android has this issue.

There is the new permissions for locations. Accurate and not so accurate.

Apps are told that "you are given coarse location" so they refuse to work.

Same for contacts. I refuse to use truecaller because it "requires" contacts access. I don't want it so I am at an impasse.

Permissions should be transparent. As you said, if the user decides on system level to disable location, apps should be told "no signal" or "no location for now, carry on"

[michaelmior]

> 2. Make Android present convincing fake data to apps when permissions are denied

What about apps that aren't malicious? How can they tell the difference between a user who denied the permission to reasonably offer alternatives?

[amluto]

As a good rule of thumb, apps are malicious. If they are not, the libraries they include are. If, somehow, even the libraries aren’t malicious, the attackers who compromise the app or its backend are definitely malicious.

[HeavyFeather]

With that logic you really shouldn't use your computer.

[fbdab103]

We are rapidly approaching that point. Apple is/was/will going to enable on-device scanning for someone's definition of naughty. Not hard to imagine that naughty will soon includes images of Winnie the Pooh, union formation, abortion, minority group X, what have you. Automatic notification of the authorities to follow.

Edit: To be clear, I am obviously opposed to CSAM, but on-device scanning is a privacy violation. Nobody knows what hashes trigger a flag, and they could be updated at anytime without the user being aware.

[wilg]

The problem is the top-level poster was also suggesting banning apps based on their definition of naughty (and "related" features).

[flangola7]

Running arbitrary and proprietary code without being able to review it first was always a mistake but we crossed that bridge over twenty years ago.

Every OS and chip manufacturer is working towards "secure core" architectures now. Executed code will run inside OS and silicon-level sandboxes. Memory spaces will not only be randomized, but encrypted and authenticated through dedicated secure enclaves. Hardened IOMMU modules will negotiate bus communication. System code is partitioned off and verified through hardware root of trust.

Malware as we have known it will be extinct in a few years.

[saagarjha]

I wish you’re right but I don’t see how what you’ve mentioned stops most malware.

[flangola7]

In a nutshell, because an application won't be able to do anything evil. We're already halfway there on mobile devices. An Android app cannot access system files or files of other apps, period. "Run as admin" doesn't exist. It can't access shared files like camera photos or documents without explicit user permission.

This is mostly accomplished using SELinux, which is an afterthought slapped onto the original OS architecture.

There are exploits that defeat these walls, but it's getting harder. Walls built from the hardware level up will be almost impenetrable and might require finding an error in the chips' microcircuit designs.

[Eumenes]

I have almost no apps installed on my smart phone ... I just go to the mobile website. Way easier, way more I can control. I'm literally missing nothing.

[supertrope]

Do you want to install our app?

[YES] [Maybe later]

[fbdab103]

Reminder the user on the screen that permissions have been denied?

[vitehozonage]

>2. Make Android present convincing fake data to apps when permissions are denied

GrapheneOS can do this. I believe you can even choose to make only chosen photos visible to a certain app

[charrondev]

This functionality is built into iOS as well.

[GoblinSlayer]

iOS implements access permissions, GrapheneOS implements sandboxing.

[UncleMeat]

#1 is a nice recommendation, but not trivial.

You've got three major systems for detecting policy violations: static analysis, dynamic analysis, and human interaction. You don't want too many false negatives or else you get bad media coverage complaining that you aren't doing enough to enforce policy. You don't want false positives or else you hurt benign users.

Static tooling will be able to detect specific kinds of ways that an app might refuse to work if you don't have a permission, but will struggle mightily in general. Dynamic analysis needs to be driven to the specific feature that triggers the behavior. Both will struggle if the app's response is something like returning to a home screen with a custom message. And good luck teaching one of these systems what "disabling unrelated functionality" looks like.

Human interaction works better but is a gazillion times more expensive. Training people is also harder than one might think. You can train humans to identify "disabling unrelated functionality" but that's fuzzy enough that there are going to be some errors. Doable, but every single new policy costs significant amounts of money.

Policy overload is also a problem for developers. There are already a lot of rules on both app stores. Developers get a new "hey this is a new rule you need to comply with" email all the time. You can only roll things out so fast or developers will get overwhelmed with just validating that their apps remain in compliance.

These are often solvable problems in isolation, but when taken as part of the overall effort of policy enforcement on app stores they become quite a bit more challenging.

[causality0]

I seem to remember this worked a lot better a few years ago. Nowadays you can't even deny an app permission to access the internet.

[aembleton]

I can deny the internet to individual apps on my Pixel 7 running Android 13. I can even deny just mobile data.

I often do it when I first install an app that shouldn't need internet access.

[akomtu]

Isn't the entire business model of Android that it's a data collection platform with zillion of sensors linked to PII that apps and phone vendors can use for profit? If Android did what you're siggesting, Samsung and others would simply fork Android and cut ties with Google.

[zaphirplane]

It’s ok to give credit to Apple for doing this already

[plagiarist]

> Make Android present convincing fake data to apps when permissions are denied.

I have wanted this for years. I eventually left Android because the permissions models were deranged (IIRC the number of apps that "need" phone access to pause something during a call). iOS isn't perfect but they seemed to be enforcing your prong #1 at least a little more than Android when I switched.