Features
What Guard does, and where each responsibility lives.
Each operating system enforces the policy with its own native stack: WFP plus a local hostname proxy on Windows, a packet tunnel on iOS, VpnService on Android, pf on macOS, and nftables on Linux. The decision is always made on the hostname carried in the TLS ClientHello or the HTTP Host header.
The panel stores your selections; the API compiles them into a flat payload containing allowed hosts, inspection domains, content rules and schedules. Devices never interpret business rules, they just apply the compiled list and report the version they are running.
Some sites are all-or-nothing, others are not. A content rule lets you approve specific YouTube channels or playlists while the rest of the site stays blocked. Inspection only ever touches the domains attached to an active rule.
Content inspection needs a local certificate authority. The app generates it inside the operating system keystore and installs the public certificate into the system trust store. The private key has no path to the server: the API has no endpoint and no column that can accept one.
Devices queue every allow and block decision in a local database and upload them in compressed batches. The dashboard turns that into daily trends, the most frequently blocked hosts, and a searchable table you can export.
Higher plans add time windows, so the allowlist can differ between school hours and weekends. Every plan caps how many devices can be enrolled at once, and revoking a device takes effect on its next policy check.
On Android 7 and later, applications ignore user-installed certificate authorities. Content rules therefore apply in browsers only, and the policy compiler blocks the native YouTube app whenever YouTube content rules are active.