Prominent disclosure
Where and how Haven tells the user what a sensitive capability does, before asking for it.
The rule Haven follows: the user is told in Haven's own words, in plain language, before the system dialog appears — never only inside the system dialog, and never after the fact.
VPN#
Before the request. Turning protection on from the main switch shows Haven's own explanation first. It exists because Android's consent dialog says "VPN" and says nothing about why a gambling blocker wants one — a fair thing for a user to be cautious about.
The explanation covers: that Haven has no VPN servers and routes nothing anywhere, that only DNS lookups are seen, that other traffic is untouched, and that Haven cannot see what the user does online.
The user can back out. Nothing has been switched on at that point, so there is nothing to undo.
During the request. Android's own consent dialog, which Haven cannot skip, style or suppress.
While active. A persistent notification, plus Android's own permanent VPN indicator. The user is never in a state where Haven is filtering invisibly.
(One deliberate exception: the onboarding route has already explained protection in its own dedicated step, so Haven does not stack a second explanation of the same thing on top of it. The disclosure is made either way — once.)
Accessibility service#
Before the request. The setup step explains, in plain language, what the service is for and what it reads:
- which app is open;
- in known browsers only, the web address and the visible page text;
- that page text is never saved and never sent anywhere;
- that only a matched website name goes into the user's own filters and log, on their phone.
During the request. Android shows the service description on its own settings screen. Haven's description is reproduced in full in Accessibility service — it names each thing read, and states the retention and transmission rules explicitly rather than in general terms.
Afterwards. Haven checks whether the service is actually running and says so. A screen will not claim an app "stays closed" when the layer that would do it is inactive — it names the missing switch instead.
On update. Android silently revokes the permission whenever the app updates, so Haven re-offers it rather than treating an old decline as permanent.
Device administrator#
Before the request. The setup step states that it only stops Haven being deleted on impulse, and that Haven uses no other administrator power — no access to data, screen or password.
During the request. Haven supplies an explanation that Android's own "activate device admin?" screen displays, saying the same thing.
On deactivation. Android shows Haven's warning text before the user proceeds.
All three texts are rendered in the language the user chose in Haven, which has to be applied explicitly because these surfaces sit outside Haven's own activities and would otherwise follow the phone's language.
Package visibility#
Disclosed at the point of use rather than as an abstract permission notice. The manifest also carries the reasoning inline:
Package visibility (Android 11+).
QUERY_ALL_PACKAGESlets the Financial Protection setup show a picker of the user's installed apps, so they can select which bank/payment apps to guard themselves instead of typing package names. The list is only read on-device to build that picker and to re-launch the single app the user chose to continue to; nothing about installed apps is stored or sent off-device.
Uninstalling another app#
Never silent and never automatic. Haven only ever opens Android's own uninstall confirmation, which names the app being removed, and the user can cancel.
Skippability#
Two of the three sensitive capabilities are skippable, and Haven does not nag:
| Capability | Required? |
|---|---|
| VPN | Needed for the core filter; the user chooses whether to enable protection at all |
| Accessibility service | Skippable. Haven states which layers are inactive without it |
| Device administrator | Skippable. Protection works fully without it |
Pushing harder on permissions this significant would only teach people to grant things they do not understand.
The one thing Haven does insist on is a PIN, and that is an in-app setting rather than a system permission. The reasoning is on Tamper protection.
Listing material#
The Play listing includes screen recordings of the accessibility disclosure, the special-use foreground service, and the package-visibility flow in context.