I was setting up a scheduling app for my team and stopped when it requested contacts, location, and microphone access. None seemed necessary for the task, but denying them blocked parts of setup. Do you read every permission screen, and how do you decide whether to accept, deny, or abandon the app?
A navigation app asking you to provide location makes sense to me. However, a scheduling application, which requires access to your microphone before being able to create a calendar, does not.
I read their permissions in brief and then ask myself if accessing any of the resources would be necessary while using the application. Inviting a contact by name may make sense, but scheduling an event with a contact should allow me to manually type their name. The application should ask for location access in cases where time zone differences are a concern, but I shouldn’t be obligated to provide it if I’m willing to type my city and state. Accessing my microphone should only occur if I choose to dictate text or make a phone call.
I also check what I had denied the application. The best response is to inform the user and move on to the next step if possible. If an application denies me the ability to do what I want or continues to prompt me to give access unrelated to the task at hand, I move on. The worst offender is an application asking for unnecessary access outright instead of waiting for me to attempt using the relevant part of the program.
Check if the web version will allow you to complete setup without granting device acess. This is often the fastest way to distinguish between account setup features (required) and device features (optional) for a team application.
I don’t read every line, but I stop at sensitive permissions. Contacts are especially important here because you may be sharing coworkers’ information, not only your own. I’d be less willing than @carl2003 to grant access temporarily just to see what happens when other people’s data is involved.
If the fundamental scheduling is protected by the microphone, location, and contacts permission, I would request this app’s curators to reconsider their decision. It produces an unacceptable outcome when all of these permissions are required to approve the same team.
Pause the rollout and ask the app vendor for permission-by-permission justification before anyone on the team installs it. A proper justification would tie each one to a specific feature and state whether the information is kept on device, uploaded or shared with third parties. That’s not needed for “best experience”.
I don’t read permissions line by line, but I do notice if an app is asking to access information beyond its core features. The reason the access is denied is interfering with setup, but that is more of a lazy app design than a requirement.
@matrixspark7531 makes a strong point about contacts involving other people’s data. People often treat contact access as a personal privacy decision, when an address book may include coworkers’ phone numbers, private email addresses, notes, and old contacts who never agreed to be uploaded. Even if the app only wants to suggest invitees, it should offer another route.
I’d judge the requests separately:
- Contacts could support invitations, but manual entry or a company directory should work.
- Location might automate time zones, though account settings can handle that.
- Microphone access should have no place in basic calendar setup unless voice notes or meetings are being configured at that moment.
Looking through a browser version is helpful, but I would not consider that a definitive answer. A browser may avoid permission prompts from the device, but collect the information anyway upon logging into the software. Permissions on a device and what the company does with the data are two separate issues.
In the case of an individual application, one might be tempted to accept the risk for the sake of convenience, but for a group deployment, the default must be to decline. One person’s acceptance of the terms may result in the collection of data concerning every person on the team. If the vendor is unable to provide a satisfactory explanation, I would not waste time attempting to circumvent the permission prompt; I would ask the person responsible for the deployment to select a different vendor with more privacy-conscious software.
Don’t test it on a phone full of real contacts.
Use a spare device, work profile, or test account with an empty address book and dummy calendar. That lets you grant the permissions long enough to see what the app actually does without handing over employee data. In that limited setup, I’m less strict than @matrixspark7531 about temporary access because the permission has nothing useful to collect.
Once you set them up, take away EVERYTHING and test out some basic scheduler functions. If the application is fussy, nagging, or simply refusing to run, you know immediately that you’re dealing with unecessary permissions.
I don’t particularly care for permission prompts, rather I look to see if the software performs as expected with a limited subset of permissions. A nice explanation from the vendor is little use to me if “no” isn’t really an option.
An app asking for permission when the user opens up the corresponding feature is consent. An app asking several permissions before any meaningful setup is mostly training users to allow by default.
That’s more important than most of the other reasons listed, because people learn through practice that software their company approves of gets everything it asks for, and they’ll apply that lesson again and again to every other app. Permission fatigue is a serious security risk on its own.
@compiler.bit’s test-device approach can reveal what the app does, but it does not fix that design. Employees will still face the same pressure on their real phones.
I read prompts that are sensitive, not every sentence. If “deny” prevents unwanted setup, I consider this permission to be obligatory, and I evaluate the app accordingly. Referring to something as optional is not a way to make it optional.
If your team uses managed phones, it’s not really a choice anymore. Whatever admin runs the phone device manager can just enable or disable certain permissions throughout the company before any installations happen, and could very well push the app to users with contacts and microphone access already denied. So before a single user gets permission prompts, discover if the phones are enrolled in an MDM (Mobile Device Management) system. If so, the ‘deny and see what breaks’ process only needs to be done once, on a central server, not twelve times in users’ hands.
That’s my main issue with the test-device idea from @compiler.bit. It’s a solid way to learn what the app actually does, and I’d run it. But it tells you nothing about what happens when everyone else installs the same thing on their real phones with no work profile. One clean sandbox result does not scale to a team that just taps Allow to get on with their day, which is basically the point @omegatiger8344lab was making about training people. Both are right, they just answer different questions.
One thing that is worth noting that hasn’t been brought up here is that on current Android / iOS, an application cannot actually force a permission through the OS. If setup ‘blocks’ on denied contacts, then it’s the app’s internal logic that is refusing to proceed, not actually a technical requirement. Sometimes it is even outright dumb; the app tries to call a method that assumes the permission is granted, but the permission is denied, and the developers never added code to handle that scenario, so it simply freezes. A bug that pretends to be a privacy concern. Now, that doesn’t change your ability to make the choice, but it does tell you that the vendor doesn’t actually put nearly enough thought into the product to be trusted with anything else that might have data.
The practical thing to do here for a wider team rollout would be to deny all permissions, take a screenshot of wherever the setup process dead-ends and submit that to the vendor and ask them exactly what is problematic and what is the specific reason. If they can show you a way to get past it without granting the permissions, then you know it’s safe. If they say that something like scheduling will refuse to work, that is your answer and you buy a ticket to the next train station. It is important to remember the objection to contacts here, since uploading coworkers’ numbers and old personal contacts is the one thing you cannot undo easily.
