Building a Child-Safe Broadband Ecosystem: The Real Challenges
Regulation, encryption, UX, and the problems ISPs won't talk about.
The regulatory pressure is real
The UK's Online Safety Act, Ofcom's enforcement framework, and growing political pressure on tech platforms have created an environment where "we provide the pipe, not the content" is no longer an acceptable position for ISPs. Parents expect their broadband provider to offer some level of child protection. Regulators expect it too. And the ISPs that position themselves as actively solving this problem — rather than grudgingly complying with minimum requirements — have a genuine commercial advantage.
But there's a gap between the expectation and the reality. The expectation is a simple toggle: "make the internet safe for my child." The reality involves deep technical challenges that most ISPs would rather not explain to their customers — or their board.
Challenge 1: Encryption is winning
DNS-based content filtering has been the standard approach for a decade. The ISP intercepts DNS queries, checks them against a categorisation database, and blocks resolution for domains in restricted categories. Simple, effective, and it worked well when DNS was plaintext.
Then came DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). These encrypt DNS queries end-to-end, making them invisible to network-level filtering. Firefox, Chrome, and most modern browsers support DoH. Android has a system-level DoT toggle. A technically savvy teenager can bypass any DNS-based parental control in about thirty seconds by changing a browser setting.
The countermeasures exist but they're aggressive: block DoH endpoints at the network level (which breaks some legitimate services), force all DNS through the ISP resolver via router-level redirection, or detect and block DoH traffic patterns using deep packet inspection. Each approach has trade-offs between effectiveness, breakage, and privacy implications. There's no clean solution — only least-bad options that need to be layered together.
Challenge 2: VPNs and proxy services
Any network-level control can be bypassed with a VPN. A child connects to a VPN server, and all their traffic is encrypted and tunnelled past the ISP's filtering. The ISP sees a single encrypted connection to an IP address — no DNS queries, no SNI headers, no content to categorise.
VPN detection is possible but imperfect. Known VPN server IP ranges can be blocked, but new servers appear constantly. VPN protocol fingerprinting works for common protocols but is defeated by obfuscated protocols designed specifically to evade detection. And blocking VPN traffic entirely creates problems for parents who use VPNs for legitimate work-from-home purposes.
The pragmatic approach is layered: detect VPN usage and alert parents rather than silently blocking it, combine network-level controls with device-level awareness, and make the default experience good enough that most children don't bother trying to bypass it. The goal isn't perfect enforcement — it's raising the bar high enough that circumvention requires deliberate effort, and that effort is visible to the parent.
Challenge 3: The UX problem
This is the challenge that gets the least attention and causes the most failure. Technical capability is worthless if parents can't use it. And most parental control interfaces are designed by engineers for engineers — dense configuration panels, obscure categorisation taxonomies, and settings that require understanding of DNS, IP addresses, and network architecture.
The parent who most needs parental controls is the parent who least understands technology. They don't want to configure a DNS policy. They want to tap "make it safe for my 8-year-old" and have sensible defaults applied automatically. They want to see what their child is doing in plain English, not in domain names and category codes.
This means age-based profiles with pre-configured policies. It means showing "TikTok — 1h 23m today" instead of "tiktok.com — 847 queries resolved." It means a bedtime toggle that says "internet off at 9pm" rather than a scheduling interface with start times, end times, and day-of-week matrices. The technology under the hood can be sophisticated. The interface has to be simple enough for a grandparent to operate.
Challenge 4: App-level encryption
Even when DNS filtering works perfectly, it only tells you which domains are being accessed — not what's happening within them. YouTube is an education platform and an exposure risk simultaneously. TikTok serves dance videos and self-harm content on the same feed. Instagram has a kids' version and a version that enables contact from strangers. Blocking the domain is a blunt instrument when the problem is specific content within a broadly acceptable service.
App-level content moderation is the platform's responsibility, not the ISP's. But parents don't make that distinction. They see "I have parental controls enabled" and expect comprehensive protection. Managing this expectation gap — being clear about what network-level controls can and can't do — is as important as the technology itself.
Challenge 5: Privacy when profiling children
Effective parental controls require monitoring what children do online. That means logging DNS queries, tracking app usage, recording screen time, and potentially analysing content patterns. This is surveillance, even when it's well-intentioned and parent-authorised.
GDPR and the UK Data Protection Act apply to children's data with enhanced protections. The Information Commissioner's Office has published the Children's Code (Age Appropriate Design Code) which sets specific standards for how services handle data from users under 18. ISPs offering parental controls need to be crystal clear about what data they collect, how long they retain it, who can access it, and what happens when the child turns 18.
The right approach is minimal data retention, local processing where possible, and transparent parent-facing dashboards that show exactly what's being tracked. Activity logs should age out aggressively — days, not months. The parent needs enough visibility to keep their child safe without the ISP building a comprehensive behavioural profile of a minor.
What actually works
No single technology solves child safety. What works is a layered approach that combines network-level controls (DNS filtering, DoH blocking, VPN detection), device-level awareness (app detection, screen time tracking), physical enforcement (smart plugs killing power to gaming consoles at bedtime), and a user experience simple enough that parents actually configure and maintain it.
The ISP's unique advantage is that they control the network. Device-level apps can be uninstalled. Browser settings can be changed. But the router sits between every device in the home and the internet, and the parent — not the child — is the account holder. Network-level enforcement is the one layer that a child can't trivially remove.
Combining that with IoT-based physical enforcement — a smart plug on the Xbox that cuts power at bedtime regardless of what the child does with the console settings — creates a level of control that's genuinely hard to circumvent. The network layer handles the digital side. The physical layer handles the hardware. And the dashboard ties them together in something a parent can actually manage.
The bottom line
Building child-safe broadband isn't a feature — it's a sustained engineering effort against an adversarial environment where the technology landscape shifts constantly. Encryption defeats DNS filtering. VPNs bypass network controls. UX complexity means parents don't use the tools. But the ISPs that solve these problems — imperfectly, iteratively, with layered defences and simple interfaces — will own the most valuable positioning in consumer broadband: the provider that families trust with their children's safety.
SONIQ Networks
Layered child safety, built into the broadband.