Blocking mechanisms

Haven blocks gambling through four independent layers. They are deliberately independent: if one cannot act — a permission was not granted, a site is brand new, an app is sideloaded — the others still do their job.

All four run entirely on the device.

Layer 1 — DNS filtering through a local VPN#

The main layer, and the only one that is on by default once the user enables protection.

Haven registers a local VpnService. It does not route the device's traffic anywhere. It assigns a virtual DNS server address and routes only that address into the tunnel, so:

• every DNS lookup the device makes is handed to Haven;
• all other traffic — web, video, messaging, banking — bypasses the tunnel entirely and is untouched.

For each lookup Haven:

1. parses the DNS question and extracts the hostname;
2. asks the on-device detection engine whether that hostname is gambling-related;
3. if it is, synthesises an NXDOMAIN answer — as far as the browser or app is concerned, the site does not exist;
4. if it is not, forwards the query unchanged to a public upstream resolver over a socket that is explicitly excluded from the tunnel, and writes the real answer back.

Both IPv4 and IPv6 are captured. If a device rejects the dual-stack tunnel configuration, Haven falls back to IPv4-only so protection still comes up rather than failing silently.

Known public DNS-over-HTTPS and DNS-over-TLS resolver hostnames are themselves on the blocklist, so a client that tries to reach one falls back to the filtered system resolver.

See VPN service for the permission and privacy detail, and DNS resolution for what reaches the upstream resolver.

Layer 2 — Gambling-app block#

Blocking a website does not help if the operator also ships an app. Haven's accessibility service sees which package comes to the foreground and classifies it.

The classification reuses the same engine as the DNS layer rather than a separate app blocklist. Android package names are reverse-DNS names, so a package can be turned back into a hostname and judged by the full domain engine; the app's display label is judged the same way as a second signal; and a curated list of well-known operator namespaces acts as a third belt.

The practical consequence: when a new operator is added to the synced blocklist, their app is recognised too, without an app update.

A detected gambling app is sent to a calm full-screen wall instead of opening. From there the user can go home, open Haven, or hand the app to Android's own uninstall dialog — Haven never removes anything itself; the final tap is always the user's, in the system dialog.

System namespaces (the launcher, Settings, the system UI, the package installer, OEM system suites) are exempt from the heuristic layers. A false positive there would not be an annoyance, it would be an unusable phone.

Layer 3 — Blocked-site redirect in the browser#

When the DNS layer refuses a domain, the browser shows a cold "site can't be reached" error. That is a bad moment for someone fighting an urge: it reads as a technical malfunction and invites retrying.

So for known browser packages only, Haven reads the address bar. If it shows a domain the rules block, the browser error page is replaced with a short breathing moment that then moves on to neutral ground.

This layer only ever reads the address bar of a browser. Every other app's window content is ignored.

Layer 4 — Page-content watch#

The safety net for gambling sites the domain rules do not know yet — new domains, mirror domains, and the numbered "brand45.com" spins that operators cycle through.

When a browser shows a host that the domain rules neither block nor allow, Haven takes one pass over the page's accessibility tree and scores what it finds through a multi-signal risk engine. No single signal can block on its own: a verdict needs a gambling-specific anchor, and a block additionally needs two separate positive scans of the same page. See Detection layers.

When a page is caught, three things happen:

1. the same calm redirect as a DNS block;
2. the domain is added to the user's own filters, so the DNS layer refuses it from then on — the protection teaches itself the new site;
3. the catch is recorded in the block log with its reasons, and in a reversible learned-sites list.

The page's text is read in memory and discarded. It is never stored and never transmitted. Only a matched domain name is written down.

What each layer needs#

Haven is explicit about this in the interface rather than implying more coverage than it has. The App-check screen, for example, will not claim a flagged app "stays closed" when one of the two switches is missing — it names the missing one. An app that looks protected but is not is worse than one that is honestly off.