Two viewing modes

Full YouTube, filtered — the real YouTube UI, every video checked before it plays.

Curated Feed — a locked-down grid of approved videos only. No search, no recommendations. Always-on for Android TV.

The request loop

Blocked channel → child taps "Ask Parent" → parent gets push + chat message → one-tap approve → overlay lifts. Kids get agency; parents keep control.

The machine-wide / per-user dilemma

Enterprise browser policies live in HKLM — admin-protected, but they hit every account on the machine. A real family reported our filter locking down all four Windows accounts on a shared PC. Move the policy to the child's HKCU hive and the opposite failure appears: a user owns their own hive, so a standard child account can simply delete the policy.

What per-child enforcement actually takes today

• A LocalSystem watchdog service watching each protected child hive and automatically re-applying any tampered policy (engineered; in final Windows build & VM testing)
• Loading logged-off users' registry hives from disk (NTUSER.DAT) under backup/restore privileges — the most fragile operation in the product
• Admin-only configuration in HKLM as the source of truth, so the child cannot reach the switch
• Code signing via Microsoft Trusted Signing — because an unsigned auto-start service that rewrites browser policy looks like malware to SmartScreen

Child-account detection is a guess

The only registry signal that an account belongs to a child is Family Safety's parental-controls key — reliable only when Family Safety is actively configured (we rate it 50–70%). Windows has no queryable, guaranteed "this is a child account" API for third parties.

The ask hiding in this slide

A supported OS primitive — per-account policy scoping with child-account attestation — would collapse thousands of lines of privileged C++ into an API call, for us and every safety ISV after us. Nobody is better placed to define it with Microsoft than the team that built the workaround.

The technical problem

There is no OS API that answers "is this a child’s account?". The only signal is a Family Safety registry key (HKLM\...\Parental Controls\Users\{SID}\Web) that exists only when Family Safety is actively configured — we measure it 50–70% reliable. The workable fallback is inverse logic: use CheckTokenMembership to prove the user is not an administrator, and refuse to protect admin accounts. Software ends up asking the parent to identify the right account, then hoping.

The solution we propose

A signed-app API returning the account’s minor status, coarse age band, and consenting parent — set once by the parent at account creation (Windows already asks for date of birth on Microsoft accounts), gated by parental consent, readable only by attested safety software. The same authorization pattern we already build against on iOS.

For apps like WhitelistVideo

Installation targets the right account deterministically. Age-appropriate defaults (safety level, category templates) configure themselves from the age band instead of onboarding questions. The trust chain — OS attests, app enforces — replaces every vendor’s home-grown detection.

For parents

Setup stops being a quiz about Windows account types. Protection lands on the child’s account and only there, on the first try — and the parent’s own account is provably untouched.

The technical problem

Browser enforcement policies (ExtensionInstallForcelist, incognito off, DevTools off) live in HKLM: admin-protected but machine-wide — on a shared family PC they lock down the parent’s account too (a real customer hit this across 4 accounts). Move them to the child’s HKCU and the protection becomes self-removable: a standard user owns their own hive and can delete any key in it. The OS offers no admin-protected, single-account policy scope.

The solution we propose

A first-party primitive: policy entries bound to a target account SID, writable only by administrators, enforced by the OS for that account alone. The child’s processes read it; the child’s account cannot write it. Everything our LocalSystem watchdog service does today — hive loading under SeBackupPrivilege, tamper re-application, logon-session tracking — collapses into one supported call.

For apps like WhitelistVideo

Deletes the most dangerous code in the product: a privileged auto-start service parsing offline registry hives. Smaller attack surface, no AV heuristics tripped, no fragile RegUnLoadKey failure modes — and every safety ISV after us inherits the primitive instead of rebuilding the workaround.

For parents

One installer run by the parent protects exactly the chosen child account. The parent’s own browsing, the other siblings’ accounts, the grandparent’s profile — all untouched. Shared family PCs finally work the way families actually use them.

The technical problem

Every gray-zone video today costs a cloud round-trip: extract metadata → call our server → server calls the LLM → verdict returns. Average ~3.5 seconds per analysis, real per-call cost (we meter every token), and video metadata leaving the device. Our engine is already disciplined about scarcity — 72-hour verdict cache, dedup gates, per-child rate limits — but the ceiling is architectural: the model is on the wrong side of the network.

The solution we propose

Port the AI Shield scoring engine onto the Windows AI APIs (systemAIModels capability): Aion Instruct for metadata/intent evaluation, Image Description for frame-level checks, the built-in Content Moderation API for severity screening. We ask for early access to the Aion Instruct transition (retail Nov 2026), a named engineering contact, and guidance tuning content-moderation severity for child contexts.

For apps like WhitelistVideo

Zero marginal inference cost removes the economic cap on analysis — every video can be graded, not just the gray zone, enabling parent-defined categories on our roadmap. 30,074 logged production analyses become the benchmark corpus for validating on-device parity.

For parents

Verdicts before the video loads instead of seconds after. Works on the school bus with no connection. And the privacy story becomes physical: nothing about what your child watches ever leaves the laptop.

The technical problem

Today, classification requires platform-specific plumbing: for YouTube we extract titles, descriptions, tags and channel data through DOM scraping and APIs — pipelines that break when platforms change markup and that don't exist at all for arbitrary sites, native apps, or embedded video. The content is right there on the screen, but there is no OS service that can look at it and say what it is.

The solution we propose

A Windows AI API that classifies any media the app hands it — screen capture, photograph, video frame, or raw text — into a hierarchical taxonomy: educational vs entertainment; entertainment into movies / anime / cartoons / gaming; each leaf scored for age-band appropriateness, with content signals and confidence. Alongside the taxonomy, a hard-block tier: nudity, gore, and explicit content detected and flagged unconditionally — blocked regardless of any category the parent has allowed. The loop is simple: app captures → SLM classifies on-device → app blocks or allows what's on screen.

For apps like WhitelistVideo

Platform plumbing disappears — no DOM scraping, no per-site adapters. The same capture-classify-enforce loop covers YouTube, TikTok, a native app, or a website that launched yesterday. Our deny-by-default policy pipeline stays; the SLM becomes its universal sensor, and our production taxonomy (7 categories, age multipliers, 30,074 logged verdicts) seeds the classification schema.

For parents

This is what makes the segment of one real: a parent's intent — "educational content and age-appropriate anime, nothing else" — enforced on everything the screen shows, not just the platforms an app happens to support. And beneath every preference, a non-negotiable floor: nudity, gore, and explicit material are blocked no matter what. Private by physics: the screen never leaves the machine it's displayed on.

The technical problem

What our installer must do — write HKLM browser policy, force-install an extension, disable incognito and DevTools, run a service at boot — is precisely the behavioral signature AV heuristics and SmartScreen are trained to flag. Unsigned, it’s quarantined. Signed, reputation still accrues slowly per-binary: each release restarts the trust clock, and during that window real parents see "Windows protected your PC" over software they chose to install. One of our production bugs (DNS-over-HTTPS forced off) came from policy hardening we added partly to look less suspicious.

The solution we propose

A recognized attestation path for parental-control software: Trusted Signing–signed safety binaries declaring a policy manifest (which keys, which scopes, revocable) get expedited SmartScreen reputation that carries across releases — plus a clear Store lane (MSIX + runFullTrust) for policy-writing apps. Microsoft already gates drivers and AV vendors this way; child safety deserves the same lane.

For apps like WhitelistVideo

Trust stops resetting on every release. The bypass-prevention layer — the product’s core value — stops being punished for existing. And the manifest gives Microsoft an audit surface: declared policy writes it can verify, instead of heuristics it can only guess with.

For parents

Installing child-safety software looks like installing trusted software — no red interstitials, no "run anyway" training that erodes the very security instincts parents are trying to teach.