Web Filtering

The panel opens on categories rather than on a search box, because typing addresses one at a time is a losing game against an internet that adds new ones every hour. Each category is a switch with a plain label, a one-line description of what sits inside it, and a number showing how many attempts it stopped in the last seven days. That number is the useful part: a category that blocked forty attempts on Tuesday afternoon is worth a conversation.

Underneath sits the allow list, where individual sites go when a category has been too broad. It is deliberately short and manual, because an allow list that grows to fifty entries is telling you a category is wrong for your family rather than that fifty sites are special.

To the right you get the recent attempts: the address, the category that matched, the time, and which child. Attempts are grouped, so four tries at one site inside three minutes appear as one line with a count rather than four rows. Everything here is set per child, because a nine year old and a fifteen year old rarely need the same rules.

When a browser opens a site it first has to turn a name into a network address, and it does that before a single byte of the page exists on the phone. That lookup is the point where the filter acts. The child app runs a resolver on the device, sees the name being requested, checks it against your switched-on categories, and either lets the lookup complete or answers with the block screen instead. The site is never contacted, so there is nothing to render, hide, or blur.

This matters more than it sounds. Filters that load the page and then cover it up have already downloaded the content, which means the thing you were trying to avoid was on the device for a moment and may sit in a cache afterwards. Deciding at request time avoids all of that.

Because the decision is made on the name alone, the app never looks inside the traffic. It does not read the contents of pages, it does not open messages, and it does not inspect what a site sends back. It knows an address was requested and whether it matched a category you switched on. That is the whole of it, and it is a boundary we chose rather than a shortfall we are working around.

Adult content is the obvious one and it should be on for every child at every age without much discussion. Gambling is the quiet second, because the boundary between a game with loot boxes and a real betting site has become genuinely blurred, and children usually arrive at money sites through adverts inside apps rather than by searching for them on purpose. Both categories are broad, well maintained, and almost never produce a complaint.

After those two, the honest advice is to go slowly. Switching on eight categories at once more or less guarantees a false positive within a day, and the first absurd block is what turns a child from a participant into an opponent. Turn on the pair above, live with them for a week, and add one more only when something happens that makes you want it.

The situational categories are where families differ. File sharing matters more on a phone that installs things from outside the store. Dating matters at thirteen and not at nine. Violent or extreme content is worth having on for a younger child and is the category most likely to produce an awkward block for an older one researching history homework. Social networks exists too, but blocking it wholesale is usually the wrong tool, and app-level rules handle it more cleanly.

When a legitimate site lands in a category it should not be in, you allow it by name. Type the address, save it, and the next request goes through almost immediately. Allowed sites always win over categories, so you never have to switch a whole category off to unblock a school portal, a club fixture list, or a shop a crawler miscategorised.

The reverse works too. You can block a single site by name even when its category is off, which is sometimes the cleanest answer to a specific problem. Both lists appear on your child’s phone, so an exception in either direction is never a secret arrangement.

What gets written down deserves to be stated precisely, because this is exactly where products in this category tend to overreach. The log records that a request to an address was made, which category matched, the time, and whether it was blocked or allowed. It does not record the contents of any page. It does not store what was typed into a search box on a site that loaded normally, it does not take screenshots, and it does not keep a copy of anything that was read. The attempt is logged. The reading is not.

Plenty of families set up filtering on their broadband router, see that it works, and reasonably assume the job is done. It is done right up until the phone leaves the house. On mobile data, on a friend’s wifi, on the network at a library, the router has no involvement at all and none of its rules apply. For a device that spends most of its life away from home, that is a very large gap.

Because the check runs on the phone itself, your categories apply on every network it joins. Home wifi, mobile data, a hotspot shared from another phone, a coffee shop connection: the same rules, the same block screen, the same log. Nothing has to be reconfigured when the network changes, and nothing quietly stops working when your child walks out of the door.

The trade-off is that it depends on the child app running with its permissions intact, and that is why the device health page exists. If the app has been force stopped, if the local network permission has been revoked, or if battery optimisation kills it overnight, filtering is not happening and you should be told rather than left assuming. A missing check-in on the health page is a signal worth acting on, and the app will say so plainly instead of showing you a reassuring green tick it has not earned.

The back door is a VPN or a proxy. If a child installs a VPN app, their traffic is tunnelled to another server before any name lookup reaches our resolver, and the filter is bypassed. Anybody claiming their product cannot be beaten this way is selling you something. What we do instead is make it visible: the proxy and VPN category can be blocked, a newly installed VPN app raises a new app alert, and app blocking can stop a specific one from running. The bypass becomes an obvious event rather than an invisible one.

Browsers with a proxy built in are the same problem in a smaller package, and worth blocking by name if one turns up. A private browsing window is not the same problem at all, since incognito changes what the browser stores locally and not where the request travels. The filter applies in private mode exactly as it does everywhere else.

The second limit is false positives, and they are unavoidable. Category lists are built by machines at enormous scale, so a small local business, a school subdomain, or a forum about a medical condition will occasionally land in the wrong bucket. When it happens the fix is quick: the block screen shows the address and the category that matched, your child requests access with one tap, and the request lands on your panel where you allow it by name. Most families settle one of these in under a minute.