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.
