Sensitive permission declarations
A consolidated reference for a Google Play reviewer assessing Haven's sensitive-permission declarations. Everything here is stated elsewhere in this documentation; this page collects it in one place.
App: Haven — Gambling Blocker (com.appblock.guard) Category: Health & Fitness / self-help. The core function is blocking gambling content on the user's own device, for a user who asked for it.
1. VpnService#
Core function it serves: on-device DNS content filtering — the primary blocking mechanism of the app.
| Question | Answer |
|---|---|
| Does it route user traffic to a remote server? | No. There are no VPN servers. Only the virtual DNS resolver address is routed into the tunnel; all other traffic bypasses it entirely |
| Does it inspect, decrypt or modify traffic? | No. TLS/HTTPS is never touched. No certificate is installed. There is no proxy |
| What does it do with a DNS query? | Blocked hostnames get a locally-synthesised NXDOMAIN. Everything else is forwarded unchanged to a public resolver over a socket excluded from the tunnel |
| Is a browsing history collected? | No. Allowed lookups are not logged. Blocked lookups go to a local log that never leaves the device |
| Is data monetised or shared? | No. No analytics, advertising, attribution or data-broker SDK exists in the app |
| Can the user revoke it? | Yes, from Android settings at any time. Haven does not detect, obstruct or fight revocation |
| Is it disclosed before the request? | Yes — Haven shows its own explanation before Android's consent dialog appears |
Foreground service type: specialUse, with the declared subtype "On-device DNS content filtering for personal protection". Filtering must run continuously for as long as the user wants to be protected; no standard foreground service type describes on-device DNS content filtering.
Detail: VPN service.
2. AccessibilityService#
Core functions it serves: blocking gambling apps; replacing a blocked site's cold browser error page with a calm moment; recognising gambling sites not yet on any list; and the user-configured reflection pause in front of money apps.
| Question | Answer |
|---|---|
| Event types requested | Window-state changed and window-content changed only |
| Capabilities requested | Window content retrieval and view-id reporting. No gesture dispatch, no global actions, no key-event filtering, no touch exploration |
| What is read from every app? | Only the foreground package name, plus its display label once per unseen package |
| What is read from browsers? | The address-bar text, and — only when the domain rules neither block nor allow the host — the visible page text and structure |
| What is read from other apps? | Nothing. All other window content is ignored entirely |
| What is read from banking apps? | Only that one is in the foreground. No content, no balances, no credentials |
| What happens to page text? | Inspected in memory and discarded. Never stored, never transmitted |
| What persists? | Only a matched domain name, in the user's own on-device filters and block log, where they can see and remove it |
| Is anything transmitted? | Nothing read through this service leaves the device, ever |
| Used for advertising or analytics? | No. The app contains no such SDK |
| Can the user revoke it? | Yes, from Android accessibility settings. Haven does not obstruct this |
Why the alternative is worse: the only other way to identify gambling pages would be inspecting network traffic, which requires breaking TLS. Reading what is already on the user's own screen, on their own device, and discarding it, is the less invasive route — and not touching TLS is an architectural rule of this project.
Disclosure: shown in-app before the permission is requested, and in the system description Android displays on the accessibility settings screen (reproduced in full in Accessibility service).
3. Device administrator#
Core function it serves: preventing impulsive self-uninstall — the central anti-relapse mechanism of a gambling blocker.
The policy file requests zero policies:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<uses-policies />
</device-admin>| Question | Answer |
|---|---|
| Which policies are requested? | None. No lock, no wipe, no password rules, no camera control, no keyguard control, no encryption control |
| What does the app gain? | Only Android's built-in behaviour that an active admin cannot be uninstalled |
| Can the user deactivate it? | Yes, two documented routes: in-app behind the PIN, and Android's own device-admin list. Neither is obstructed |
| Is it required? | No. It is opt-in and the setup step is skippable |
| Any lockout, ransom or takeover behaviour? | Impossible — the app holds no policy that could lock, wipe or change a password |
Detail: Device admin.
4. QUERY_ALL_PACKAGES#
Core functions it serves: App-check (finding gambling apps already installed); the financial-protection app picker; resolving the label of the foreground app as a detection signal.
| Question | Answer |
|---|---|
Why not a narrower <queries> declaration? | It would require enumerating every gambling operator's package name in the manifest — stale on release, and it would break the core design that a newly-listed operator is recognised without an app update. A launcher-intent <queries> element is also declared and covers the app listing |
| Is the app list transmitted? | No. On-device only |
| Is the app list stored? | Only the packages the user explicitly released as false positives, locally |
| Is it used for advertising, analytics or profiling? | No |
Detail: Package visibility.
5. REQUEST_DELETE_PACKAGES#
Core function it serves: offering to remove a detected gambling app.
Used in exactly two places, and in both it issues Intent.ACTION_DELETE for a single package. This opens Android's own uninstall confirmation. Haven never uninstalls anything, never does so in the background, and never touches an app the user did not choose. The final tap is always the user's, in the system dialog.
Data safety summary#
| Data collected and sent off-device | Email address and name (only if the user creates an optional account); marketing-consent choice; language and notification preference; purchase data handled by the billing SDK; the blocklist version number |
| Data not collected | Browsing history, page content, DNS query logs, installed-app lists, location, contacts, photos, messages, financial account data, health data, identifiers for advertising |
| Third-party SDKs | Google sign-in and Play billing; the subscription provider; the accounts backend client. No analytics, crash-reporting, advertising or attribution SDK |
| Account required to use the app | No |
| Data deletion | In-app account deletion, a deletion request page on the public website, and a contact address in the privacy policy |
| Data encrypted in transit | Yes. The release build denies all cleartext traffic with no exceptions |
| Android backup | Disabled (allowBackup="false") |
Supporting material#
The Play listing includes screen recordings demonstrating the accessibility disclosure, the special-use foreground service, and the package-visibility use in context.