Apple solved this pretty well I thought. The developer guidelines say that you cannot require a permission as a condition of using an app. If the user says no, you must gracefully degrade. You can’t exit(0) or put up an undismissable screen until you get the permission. Apps that violate this are supposed to get kicked out of the store.

That’s not quite the full story. If your app absolutely must have the permission to operate, then it can be exempted from this requirement. I imagine “absolutely must” is up to interpretation.

> I imagine “absolutely must” is up to interpretation.

There is no way for app developers to "force" additional privileges.

They still can't exit(0), but for instance a GPS tracking app (navigation, running, whatever) that isn't allowed access to the GPS can't very well function without GPS access, so in that case your app is allowed to fail.

They cannot be excempted from asking for, and abiding by the users decision, but they can be excempted for not working "as advertised" should the user not provide the needed capabilities.

YouTube TV still gets me though. Requires GPS access and won't let me access my hometown sports without it.

Probably due to the blackout provisions of the contracts to carry hometown sports.

LineageOS 16 used to have this feature. I really miss it. https://forum.fairphone.com/t/transitioning-from-los16s-priv...

Sad to have just learned from that link that Privacy Guard is gone. That has indeed been a key Cyanogen/LineageOS feature for me for years (my phone is still on 16). I can't say I understand the decision to remove it.

While for contacts and location that would be a good feature (I agree!), I'm not so sure about storage. It may be nice for certain rogue apps (or ones that request permissions they don't actually need) to give them /dev/null without them knowing, but that may actually result in bugs and unstable behaviour if apps are written to expect working storage.

Storage doesn't have a built-in failure mode like contacts and location have.

Okay, you're probably right. It might be a better option to give an app a sandboxed storage location instead, just so the files it put there remain there because it might expect to find them there later.

... isn't that exactly what access to storage does? Do any (mobile) platforms give access to NON sandboxed storage?

All apps get sandboxed storage without even asking. On Android at least, permission for "storage" means permission for an area shared between all apps. And a lot of apps dump stuff into it that you do not necessarily want every other app to have access to.

It's always been that way.

What it really needs is some kind of compartments, so that you can share storage between X and Y, and between Z and W, but not between X and W.

I just installed Signal two days ago and enabled backups.

This asked, understandably, for storage permission. This prompted me to give access to the sdcard, however, I had the option to select a single folder (or actually directly creating it within the prompt) that the app will have access to. I.e. Signal now has access to sdcard/signalbackups/ but not to the whole sdcard. (unless this whole new permission process wasn't Android but the Signal app. I rarely download apps and have to give storage permissions).

This used to be different, but times of giving access to full internal or external sdcards are over. Unfortunately though, the UX isn't perfect. I felt like I needed to know that I only want to give it access to a part of the sdcard and actively look that this is indeed possible. But that might be my bias from previous usage talking.

No, sandboxed means restricted to that application. Apps need permissions to access data outside of their sandbox. They are suggesting that there be another sandboxed storage for apps that pretends to be read data.

> Storage doesn't have a built-in failure mode like contacts and location have.

Yes it does: disk full. It's perhaps a bit less reasonable to expect a program to keep working properly in such a case, but it needs to be handled somehow.

App developers find out about this practice as it gets more commonplace. They add a check for 'empty' data or resolution failures. If these checks notice that you had been providing null or fake data, the app now gives you an intrusive yet pleading popup to please lift the privacy measures.

You get annoyed, resenting the fact that your friends are using this piece of garbage. Reluctantly you lift the measures, forget about it, and just keep using the app.

Just like with adblockers and anti-adblockers, you then go one level deeper...

It's a cat-and-mouse game. As long as you have full control over your device, you win.

At some point we're going to have to reverse engineer apps and come up with hopefully free software replacements...

That would get you banned in the Apple App Store

Although it’ll never happen a cool idea would be to serve trap addresses and phone numbers so the developer can receive an instant ban if spam ends up on these addresses

This would, of course, be immediately abused to ban competitors' apps.

You would serve a different trap address to each app, nobody but Dropbox would have the Dropbox trap.

Nobody but Dropbox and anyone with the Dropbox app on their phone. It has to get from the user's phone to Dropbox, which means it's on the user's phone at some point, barring some sort of convoluted user --> Apple --> Dropbox transfer scheme.

Right, the Dropbox app on their phone is asking the OS for contact info, which the phone generates and provides to the Dropbox app and only the Dropbox app. Any other app would get a different fake address.

Or are you talking about the scenario where competitor apps use some kind of sandbox escape to jump out and steal other apps' trap addresses from the OS?

I figure that's what @ceejayoz is talking about. This probably won't happen between 'mom and pop' apps, but maybe a failing SV unicorn might become desperate enough to pay $1MM, or however much a blackhat will ask for this service, to trash their main competitor.

Each user has their own trap email for each application. The ban would happen for that user only

This is an awesome idea.

iOS almost allows this for geo-location nowadays, where one can pick whether to give ones exact position or a much less exact position, and for photos where one can select exactly what photos the app should get access to.

Does android have this API? The problem I see is, if they are introduced in later versions, people are anyway used to apps asking these permissions and developers don't bother to use these.

Also, a question to security experts: In many apps say we want a UX where the user would immediately be able to see their recent pics and select from them (think recent photos bar in whatsapp), but app shouldn't be able to access them. Is it safe if OS provides it as a screen overlay service which doesn't require a separate screen/window, but runs out of process (a la file picker).

Android has a better API, and has had it for at least 5 years. An app can open the system UI for you to choose a file, and it would then only get access to that particular file while the activity (screen) that requested it is running. As far as the user is concerned, this requires no permissions. Under the hood, the app gets a content:// URI with an "URI permission" granted. This is also how sharing (Intent.ACTION_SEND) works. You could as well use this mechanism to expose the content in your app to other apps in a controlled manner.

Yep. Android also has a Contact Picker that doesn't require contacts permissions where you just select a single person in a dialog.

I have never seen it used in a real app. Most apps request permission to your entire address book.

iOS does this for photos as of iOS 14: https://www.macrumors.com/2020/06/24/ios-14-users-give-apps-...

I wish there was an easier way to add additional photos quickly. From what I understand the only way is search for the app in settings, open the "Photos" permission and click on "Edit Selected Photos". Is there an easier way I missed? I guess I can't expect a simple click from within the app itself while selecting photos, as it's not aware it's seeing a limited selection.

I think it requires developers to fix that. At least in Slack there's two buttons next to their in-app image picker. One opens the camera to take a photo, the other pops up the iOS photo picker overlay where you can select more images.

I used to have a rooted android phone that could do this. If I remember correctly it was called Xposed Framework. I could even fake GPS data which was extremely useful in all kinds of apps. I also remember power usage increasing significantly after I installed this.

iOS has started doing this, at least for photos.

OPPO's colourOS as this.

> The Personal Information Protection feature is a very clever way to bypass this situation. You can turn on protection for call logs, contacts, messages, and events. Once protection is enabled, ColorOS 11 will send apps empty information, tricking the app into accessing the blank data.

https://www.xda-developers.com/oppo-coloros11-privacy/

I use xprivacy lua in android that does exactly this. It's not simple for general public though and it needs root.

Does it still work in recent Android versions though?

Depends if your rom supports edxposed properly which is for android 9 onwards.

I love this idea! Unfortunately the creator of the most popular mobile OS is also one of the worst offenders in this regard.

Given how things are going with big tech lately I wouldn't be shocked to see Google implement this feature, but with exception criteria that just so happens to apply to all Google apps.

Yes, but it cannot be the sole feature. This should be done for compatibility with old apps, but also explicitly forbidden in the app stores that any app try to work around that by doing any kind of active detection.

"Sign in with Apple" kind of has something like this. It can give the application a randomly generated email address that acts as a forwarding address. The application never receives my real email address.

Not quite the same thing, but if you use Sign in with Apple, the application gets an Apple email address, and Apple forwards the email on to you.

Facebook Login used to have this as an option too, but stopped years ago.

An "easy" implementation would be to allow the user specify which contacts db is shared. User could then have multiple contact lists -- a fake one, a work one, a personal, etc.

You could check MIUI or Realme which already has that feature.

They’d detect it easily and refuse to work.

But iOS 14 let’s you do this for photos at least.

Well, from user perspective would be useful, but I don't have much expectations it would be implemented in, say, Android. They ofcourse want quality data.

Haven't done in-depth Android development, but I believe there is option to fake some GPS data? Ofcourse, not that helpful if you want 1 app to have real data, the other... not so real.

Proper way would be force devs think about REQUIRED and OPTIONAL permissions you can give. REQUIRED permissions are given on launch (or maybe you just get useless app), OPTIONAL permissions for improved features and fails gracefully if not given. It currently works that way, but is up to developer to implement it that way.

Perhaps adding advantage to those apps that do not REQUIRE sensitive permissions. Say a filter in Play Store you can use to filter our apps that require X permissions to work. In some cases, devs would be incentivized to REQUIRE less permissions.

When writing this comment, I thought about another solution. User profiles on android. Like on browser, where you get your own cookies etc. Googled around and.. looks like Android has something to offer!? Doesn't solve location, but perhaps Storage/Contacts.

https://source.android.com/devices/tech/admin/multi-user

https://support.google.com/nexus/answer/2865483?hl=en

> Notifications appear for all accounts of a single user at once.

> Notifications for other users do not appear until active. Each user gets a workspace to install and place apps.

> No user has access to the app data of another user.

> Any user can affect the installed apps for all users.

> The primary user can remove apps or even the entire workspace established by secondary users.

I'm primarily an Android developer myself and I do respect my users <s>and that's why I have no job</s>, so yes, I request permissions only when they're absolutely necessary and when it's obvious as to why the permission is needed.

The bigger problem, though, is that you can't trust bad actors to act good. DNT in browsers has showed that extremely clearly: it was meant as a marker for you to not be tracked, yet advertisers used it as an additional bit for fingerprinting. Policy might be a way, but it relies on humans looking at apps. It's always much more effective to have technical measures in place, if possible. As in, no mater how much you'd like, you can't track a user across the web if their browser doesn't accept third-party cookies. And many app developers are in no way better than web developers with their incentives, intentions and tactics, it's just that the web makes these issues more noticeable.