Parental Control Teardown Across Independent Layers Automation: Turning It Off Has to Actually Turn It Off

Applying a configuration and removing it are, in most systems, treated as mirror images of the same operation — if writing a value is understood, removing it is assumed to follow naturally. In a system that reaches outside its own database into an external, stateful surface it does not fully control — here, the Windows registry, read independently by each installed browser on its own schedule — that assumption breaks in a specific, easy-to-miss way: an "apply" operation that only ever adds or overwrites values can look, from every test that only ever turns things ON, exactly as correct as one that also knows how to take them away. The absence shows up only in the one test nobody wrote: turn a specific thing off, and check the machine, not the screen, for whether it actually happened.

Centriu Guardian's parental-control agent applies browser-level content policy by writing a defined set of registry values and list-type sub-keys (domain blocklists, allowlists, extension restrictions, and several always-on-or-off flags) under each installed browser's own policy path, with administrator elevation required for the write. The mechanism that applies a NEW or UPDATED configuration and the mechanism that REMOVES the feature entirely already existed as two separate code paths — but only the second one, `removerPoliticas`, actually deleted anything. The first one, used for every normal configuration update including one where a parent had simply unchecked something they'd previously enabled, only ever wrote values forward; it never called anything resembling a removal step. The practical effect: unchecking a single setting inside an otherwise-normal update looked identical, from the screen's perspective, to a successful save — and had zero effect on the machine, because whatever value the PREVIOUS save had written into that exact registry slot was simply left standing.

The fix folds a full removal pass into the START of every single application, in the exact same elevated administrator request that then writes the new configuration — so what ends up on the machine after any update is always and only whatever the CURRENT configuration actually specifies, with nothing left over from before.

A second, more subtle gap surfaced specifically while verifying that removal: Guardian's own status check determined whether a policy was "active" for a given browser using a simple existence check on its registry key — and a key that removal had correctly emptied of every value and every sub-item, but had not gone on to delete outright, still satisfied that existence check. The dashboard would report a filter as present and working for a browser where, in reality, every actual setting under that key had already been removed. The fix adds an explicit check, after every removal, for whether a browser's policy key is now both valueless and childless — and deletes the key itself the moment it is, so "present" and "actually filtering something" can no longer disagree with each other. The check is deliberately conservative: a key is only ever removed once confirmed completely empty, specifically so a policy belonging to something OTHER than Guardian (a company device-management tool, another program) sharing the same registry location is never touched.

The third and most consequential gap was architectural rather than a coding mistake: Guardian's parental control had always operated two genuinely independent systems under one label. Browser-level registry policy governs what a specific installed browser does. A separate, machine-wide DNS family filter — configured once, at the network level — governs which domains resolve AT ALL for that machine, in every browser, in every window including incognito, because DNS resolution happens before a browser is ever involved in a request. Deactivating the browser-level policy correctly and completely, exactly as the first two fixes above ensure, still left this second system running exactly as configured, because nothing about it was ever part of the browser-policy removal in the first place — and, critically, its existence was never disclosed to the person turning the feature off, so a fully successful browser-policy removal that still left a site blocked looked, to them, like the fix hadn't worked at all.

The fix does not silently fold the two systems together — that would remove a real, independent choice some households want to keep (the DNS filter and the per-browser filter genuinely serve different purposes, and a parent might reasonably want to keep the network-wide one while turning off browser-specific detail). Instead, the deactivation flow now explicitly names whichever DNS filter is currently detected on the machine, offers turning it off too as its own separate, clearly-labeled checkbox (pre-checked by default, since most people asking to deactivate parental control want the machine genuinely unrestricted, but still an explicit choice either way), and — after the operation completes — reads the DNS configuration back from the machine itself, not from what was merely requested, so that if a DNS reset silently failed to take effect the summary can say so honestly ("deactivated — but the DNS filter is still active") instead of declaring a blanket success that isn't true. Two smaller details close the same loop: the DNS resolver's own cache is cleared on every removal, since a cached blocked-response can outlive the policy that produced it and make a correct fix look broken for a few more minutes; and the screen now tells whoever just made the change to close and reopen their browser windows, because Chrome and Edge only re-read their own policy configuration at launch — an already-open window, even after a fully correct removal, keeps enforcing whatever it read when it started.

Before the fix, a parent unchecking a single site from an existing blocklist and saving found the browser continuing to block it, because the save path only ever added or overwrote registry values — the value from the PREVIOUS save was never removed, so it simply kept winning. A parent completing a FULL deactivation, and getting a dashboard that reported every filter as removed, could still find their own dashboard showing "filtered" for a browser whose actual policy key held nothing at all — an empty shell the status check misread as active. And a parent who confirmed every visible setting was off, then tested an adult site directly, could still find it blocked, because a second, entirely separate machine-wide DNS filter had never been part of the conversation the deactivation screen was having with them at all. After the fix, each of these now behaves as the underlying action implies: unchecking removes, an empty key stops counting as active, and the DNS layer is named, offered, and honestly reported on rather than silently left running.

Centriu Guardian's parental-control removal now clears prior configuration before every write (not only on full deactivation), deletes registry keys the moment they are confirmed genuinely empty instead of leaving inert shells that misreport as active, explicitly discloses and offers to disable a second, independent, machine-wide DNS filter during deactivation, and verifies its own success against the machine's actual post-operation state rather than assuming success from what was requested.

This automation governs the internal mechanics of how Centriu Guardian's parental-control feature applies and, specifically, REMOVES its own configuration across two independent underlying systems (browser registry policy and machine-wide DNS filtering) — it does not change what settings a parent can configure, does not add a customer-facing option beyond the DNS-layer disclosure itself, and is specific to Windows's own registry-and-DNS architecture; a system with only one enforcement layer, or one that already treated apply-and-remove as symmetric from the start, would not have been exposed to this exact class of gap.

Building a configuration-application engine that only ever writes forward is the simpler design, and works without any visible defect for as long as every test only ever turns settings ON — the gap is specific to, and easy to miss until, the first time a setting needs to come back OFF. Clearing whatever a previous application wrote before every new write, as a standing rule rather than a special case reserved for full deactivation, closes the gap for every future setting the same way, without needing a dedicated removal code path to be remembered and called correctly at each new place a change can happen.