Chrome exempts Google's domains from user site-data controls
Chrome does not enforce user site data settings against Google-owned domains. What the exempt scope means and how to treat the control.
Chrome does not enforce user site data settings against Google’s own domains. A user can configure how site data is stored and cleared. That configuration governs the sites subject to it. Google-owned properties are not subject to it. The control exists. Its scope excludes the party that ships the control.
This has occurred before. The topic states it is occurring again. Recurrence is confirmed. The number of prior instances, the dates involved, and whether earlier cases were ever closed are not confirmed. Treat the count as unknown. Treat the pattern as established. Absence of that detail is a condition of the record, not a gap to fill.
Position: a privacy setting that does not bind every party is not a privacy setting. It is a preference applied selectively. The user configures a boundary and receives a boundary with a carve-out. The carve-out favours the entity that both distributes the browser and operates the exempted domains. Identity is the boundary. Here the boundary is drawn around the identity that benefits from crossing it.
The observable behaviour is direct. A user sets a site data restriction in Chrome. Google-owned domains continue to hold site data under that restriction. The setting registers as applied. The exempted domains do not reflect it. Same interface. Different outcome by domain owner.
The control reports success while excluding a defined set of destinations. Nothing in the user-facing state signals the exclusion. The setting does not present as partial. It presents as applying to sites the user configured. The gap between presented scope and enforced scope is the failure. The user is told the control is set. For Google domains, it is not in effect.
What failed is scope integrity. A control that applies to some domains and silently omits others has no reliable meaning. The user cannot act on it. From the interface alone they cannot see which domains are governed and which are exempt. The setting produces a state the user did not select and cannot observe. That is the failure. Not the storage of data. The misrepresentation of which domains the setting controls.
The exemption is not spread across unrelated domains. It aligns to a single owner. The exempted party is Google. The party that develops and distributes Chrome is Google. The entity that defines the enforcement scope and the entity removed from that scope are the same entity. That relationship is a logically necessary implication of the stated facts, not a claim about motive.
The control’s scope was set to exclude the vendor’s own domains. That is the observable condition. Whether the exclusion is deliberate design or a repeated defect is not confirmed. Both remain consistent with the facts. When more than one explanation fits, the cause is not confirmed. What is confirmed is the shape of the outcome. The exclusion tracks ownership, and it has recurred.
Recurrence removes one defence. A single exemption could be read as an isolated fault. An exemption that returns is a property of the product as shipped. The internal mechanism, the code path, and any decision to reintroduce it are not confirmed. The external result is stated plainly: the party that controls the browser is the party the browser’s controls do not reach. A boundary that exempts its own author does not enforce. It records an intention the author is free to disregard.
The failure operates at the seam between what the interface reports and what the storage retains. A user applies a site data restriction. The interface returns an applied state. Google-owned domains retain site data under that applied state. Both facts hold at the same time. The control reports coverage it does not deliver for a defined set of domains. That set is not chosen by the user. It is fixed by the party that ships the control. The observable condition is a restriction that reads as active and a set of destinations that do not reflect it.
The exempt set is not surfaced anywhere the user can read it. From the interface alone the user cannot enumerate which domains are governed and which are omitted. Same setting, same interface, divergent outcome by domain owner. The mechanism does not require the user to misconfigure anything. Correct configuration produces the exempt outcome. That separates this from user error. What control failed is scope enforcement. Where the boundary broke is between the presented scope and the enforced scope. How the exemption is carried in the product, whether through a specific list, a code path, or a default, is not confirmed. Only the result is observable. Configured restriction, retained data on Google domains.
A control whose enforced scope is invisible cannot be verified by the party relying on it. The user sets the boundary and receives no signal of where it stops. The enforced scope and the presented scope differ, and from the interface only the presenting party can see the difference. That asymmetry is the mechanism. It is not confirmed that any warning, indicator, or log exposes the exempt domains to the user. Absence of that signal is a condition of the observed behaviour, not an inference about intent. The user acts on a reported state that does not match the enforced state, and nothing in the reported state discloses the mismatch.
The pattern derives directly from that mechanism and from one ownership relationship stated in the facts. The party that defines the control’s enforcement scope is also a party subject to the control. The entity enforcing and the entity exempted are the same identity. Identity is the boundary. Here the author of the boundary sits on both sides of it. A boundary drawn by its own subject is a boundary that subject can position. The control’s meaning depends on trust in the party being controlled, and that trust is not validated by anything the user can observe. Continuous validation is absent. The user extends trust once at configuration and receives no confirmation that the trust holds for every domain.
Recurrence sharpens the pattern into a property. A control that exempts its author once is a state. A control that exempts its author again is a characteristic of the product as shipped. Whether prior instances were ever addressed is not confirmed. That the exempt outcome returned is confirmed by the topic. A result that returns after configuration cannot be treated by the user as fixed. The user cannot durably close it from the interface, because the interface is the layer that reports the control as applied while the enforced scope omits the exempt domains. The party who can move the boundary is the party the boundary is meant to bind.
Generalise the mechanism, not the domain. Any control shipped by a party that is itself within the control’s scope inherits this shape. The enforcement point is owned by a party with a position in the outcome. When the author of a control is also a subject of it, the author holds the ability to define itself out of scope, and the subject who relies on the control cannot see that definition from the interface. If a system permits the author to exempt itself, that exemption is available to appear. The facts show it has appeared and appeared again. That is the pattern. It is derived from the stated ownership relationship and the observed recurrence, not from any outside case.
Treat Chrome’s site data setting as scoped to non-Google domains. That is its enforced meaning. Its presented meaning is broader, and the two are not the same. Do not rely on the setting as a uniform control across all destinations. For the exempt domains the setting does not stop the behaviour it names. A control that does not stop the behaviour it names is ineffective. State it as ineffective for those domains and do not soften it. This is not a statement about stored data as such. It is a statement about the retention of enforcement authority by the party the control is meant to bind.
What must now be true is narrow and testable. The enforced scope must equal the presented scope, or the interface must disclose the exempt set to the user at the point of configuration. Neither condition is confirmed present. Until one of them is met, the setting is a preference with an undisclosed carve-out, and it should not be represented to users as full coverage. The disclosure requirement is not optional, because a control the user cannot verify is a control the user cannot act on. Scope integrity is the property in question. Reported state must match enforced state, and any exemption must be visible in the reported state.
Identity is the boundary, and the browser vendor placed its own identity outside the boundary its browser enforces. That is the finding. Controls that are not enforced against their author are not controls against their author. Configure on that basis. Assume Google domains retain site data regardless of the setting until the enforced scope is demonstrated to include them. Do not treat the applied state in the interface as evidence of enforcement for those domains. If a system allows the party that ships a control to exempt itself from that control, the exemption will occur. The record shows it has occurred, and it has recurred. Plan for the enforced scope, not the presented one.
Keep Reading
flock surveillanceThe system ran one veteran 100 times
One person was queried 100+ times in a Flock tracking system. When identity is the only enforced gate, abuse completes exactly like legitimate use.
privacyThe torrent protocol shares your address by design
How an adult studio unmasked a Meta exec's John Doe torrent handle, and what the IP-to-identity pipeline means for your privacy.
MFA bypassVerification became the leak
An unauthorized live feed of every ID verification let attackers bypass MFA for over a year. Why readable verification output stops being proof.
Stay in the loop
New writing delivered when it's ready. No schedule, no spam.