- App "has" access to contacts, but the system returns that you have none.
- App "has" access to location, but the search for GPS satellites never completes.
- App "has" access to storage, but it's actually /dev/null.
- App "has" access to contacts, but the system returns that you have none.
- App "has" access to location, but the search for GPS satellites never completes.
- App "has" access to storage, but it's actually /dev/null.
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.
Storage doesn't have a built-in failure mode like contacts and location have.
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.
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.
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.
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.
It's a cat-and-mouse game. As long as you have full control over your device, you win.
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?
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).
I have never seen it used in a real app. Most apps request permission to your entire address book.
> 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.
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.
Facebook Login used to have this as an option too, but stopped years ago.
But iOS 14 let’s you do this for photos at least.
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.
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.