VPN App Asks for Contacts and Accessibility: What to Allow

The installer asks for network access, then for contacts, accessibility and a certificate install. Only the first request belongs to the job. The second screen is where the actual decision sits.

Judge each request against a feature you chose, on the platform you run. No universal permission list covers every VPN product, and a long list proves nothing by itself.

The one permission the job genuinely needs

Android asks the user to approve a VPN service through a system dialog before any tunnel starts, and the app's service declares BIND_VPN_SERVICE so the system can bind to it. Operationally the app does routing work. Consent comes from the person holding the device, in a dialog naming the app, and revoking it later is a supported action.

Apple platforms express the same idea through a network extension plus an installation approval rather than a permission screen. Windows uses a virtual adapter driver and an elevation prompt. Two shapes, one meaning: this program may handle packets. Nothing in that authorisation covers reading your address book or issuing itself a certificate authority.

Extra access is a separate grant with separate effects. A routing client that wants it needs a reason of its own.

Where the extra requests need their own story

An accessibility service can read screen content and act on your behalf, which is far beyond routing. Device administration can enforce lock policies and wipe data. A user-installed root certificate lets whoever holds the matching key read traffic that TLS would otherwise protect.

Any of those can be legitimate. Managed-device and parental-control products may need policy powers, and a support tool may need accessibility to walk you through settings.

The requirement is traceability: the request points at a named feature, and that feature is visible in the product you installed. A contacts prompt with no contact-facing screen has no explanation to offer. The encryption argument does not transfer either, because protecting packets says nothing about who your friends are. A legitimate product can still over-request through a bundled library, and that is a defect to raise rather than a crime to report.

Record the request and the feature it maps to, then decide. That note is also what you show support when a feature breaks after a denial.

Reading the request on the device

The store listing describes intent, while the installed package describes reality. Ask the package manager what was declared and what was granted before approving anything else. The pair matters most when a listing and a manifest disagree.

Two queries cover most of it:

adb shell dumpsys package com.example.vpn | grep -E "requested permissions|install permissions" -A 30
adb shell cmd appops get com.example.vpn

The first lists declared against granted permissions, which is the comparison that exposes an over-broad manifest. The second shows runtime app-ops, including special accesses that never appear as ordinary permissions. Where developer tools are unavailable, read the same facts from the platform settings screens.

Those screens take a minute and need no software. Accessibility, device administration and certificate storage each list the apps holding the grant.

Deciding, then limiting the damage

Grant the networking authorisation to a client you chose, and treat every additional request as its own decision. Deny the ones without a matching feature, then see what breaks. A routing client that fails when contacts access is refused was never asking for contacts on your behalf.

Revoking one permission usually disables a single feature without uninstalling the app or tearing down each profile. Reconnect afterwards and confirm the tunnel still establishes.

Separate the two questions a prompt tends to merge: what this program may do on the device, and what its operator does with traffic once the tunnel is up. The first gets answered here. The second needs a retention policy, and no dialog supplies one.