A small embedded panel remembers a compact layout on a shopping page but opens wide on a news page. That difference does not necessarily mean the panel forgot your choice. A browser can keep separate cookie records for the same embedded service according to the site surrounding it. Google's CHIPS documentation describes cookies that opt into this partitioned storage. [1] The useful question is therefore not just whether the panel has a cookie, but which context selects the record the panel is allowed to use.

Our original example follows a fictional layout preference named panel_mode. It belongs to widget.example.net, which appears directly inside several ordinary HTTPS pages. We assume the browser accepts the specified writes, the records remain unexpired and other applicable controls permit the requests. These are paper examples, not observations from a browser or account. We will trace three stored values, then examine a separate request rule called SameSite. Keeping record selection apart from request permission explains why changing one setting need not make every copy of the panel remember the same thing.

An embedded service can retain different values for one cookie name without a failed write or random eviction. CHIPS adds a partition associated with the top-level site to the cookie's host-related scope. Google's documentation illustrates distinct state for the same service under different top-level sites. [1] A diagnosis that records only the service URL and cookie name therefore omits a relevant selector. Conversely, a difference in top-level page origins is not sufficient to prove that the partition selector changed.

The original construction uses panel_mode on widget.example.net, direct-child embeddings, ordinary HTTPS tuple origins and explicitly assigned cookie attributes. Writes are stipulated to succeed; cookies remain unexpired; no other policy blocks the relevant exchange. No browser implementation, account or tracking behavior is measured. The model first follows storage identity and updates, then applies a separate, explicitly bounded SameSite comparison. This separation lets us explain a missing request value without pretending that one preference trace reveals every record in the browser's store or every decision in its privacy policy.

An origin identifies an ordinary web address using its scheme, host and port. A scheme is the opening part such as https; the host is the named server; a port distinguishes an endpoint on that host. The HTML Standard's same-origin comparison checks those components. A schemeful site groups more broadly, using the scheme and a registrable domain in our examples. [2] Shop.example.com and learn.example.com are different hosts, but both belong to the example.com site when the scheme is HTTPS.

Compare https://shop.example.com/store with https://learn.example.com:8443/course. Their origins differ, yet both have the schemeful site https://example.com. Changing only /store to /other keeps both identities the same. Changing the shopping address to HTTP changes its schemeful site as well as its origin; we use that address only to illustrate identity, not to send our secure cookie. The domain grouping here is explicitly assigned for example.com, example.org and example.net. It is not a general instruction to take the last two pieces of every hostname.

For ordinary tuple origins, same-origin equality requires equal scheme, host and port; URL path is not part of that comparison. The HTML Standard obtains an ordinary schemeful site using the scheme and registrable domain, falling back to the host where the registrable domain is null. It treats opaque origins separately. [2] Our fixtures use only hosts with the explicitly stated registrable domains example.com, example.org and example.net. They do not implement public-suffix resolution or model opaque and sandboxed contexts.

Let A be https://shop.example.com/store and A-sibling be https://learn.example.com:8443/course. They differ in host and port, but their site is the same pair, HTTPS and example.com. A different HTTPS port on shop.example.com also changes origin without changing site. A path change changes neither. An HTTP variant changes the scheme component of both identities. Explicit HTTPS port 443 and its omitted default describe the same ordinary origin in this fixture. These comparisons classify addresses; they do not assert that every classified address can receive the secure cookie used below.

Our preference is host-only: the imagined setting response does not provide a Domain attribute. Under the cookie rules in RFC 6265, that keeps its host scope at widget.example.net rather than extending it to other hosts. The name is panel_mode and its Path is /panel. [3] Those details matter even before partitioning enters the picture. A preference with the same name on another host or another cookie path is not automatically the record we are following. The top-level shopping page also does not become the owner of the widget's cookie.

Path matching has a boundary, not just a similar spelling. The /panel record can match /panel and /panel/view, but not /panels. The RFC also warns that cookie paths are not a security barrier and that cookies do not isolate ports in the way ordinary origins do. [3] A different HTTPS port for the same widget host is therefore not, by itself, a separate cookie compartment. Keep that fact distinct from the top-level page's port: the latter already disappeared when we grouped the surrounding page into a schemeful site.

The fixture fixes the host-only flag by omitting Domain, sets Path=/panel and uses the name panel_mode. RFC 6265 describes host-only matching, path matching and the name/domain/path relationship used when replacing an existing cookie. [3] We retain those fields while adding the explanatory partition selector. The tuple below is intentionally sufficient for the fixed example, not an exhaustive browser storage-key definition. Other attributes are held constant, and nested ancestor-chain distinctions are outside the direct-child scenario.

For cookie-path /panel, exact equality succeeds; a longer matching path succeeds when the following character is a slash. Thus /panel/view passes while /panels and /panel-extra fail. [3] This matching rule is not a path-based access-control boundary. Cookie scope also lacks the port isolation used by the same-origin model, so a port change on the widget host alone does not establish a distinct cookie record. [3] Conflating those two identity systems can make an origin table look precise while still predicting the wrong storage behavior.

For the main trace, give the record Secure, HttpOnly, SameSite=None and Partitioned attributes. Secure limits transmission to a secure channel, and HttpOnly keeps it out of non-HTTP access such as a page script's ordinary cookie access. [3] Google's CHIPS guidance requires Secure for its partitioned cookies and describes a partition key based on the top-level site's scheme and registrable domain. [1] The layout is therefore rendered by the widget's server after receiving the relevant request, not by JavaScript reading this HttpOnly value.

For our fixed attributes, write the identifying label as widget host, cookie path, cookie name and top-level schemeful site. On the shopping page its final part is https://example.com. On https://news.example.org/story it is https://example.org. The first three parts stay unchanged. The surrounding page helps select a compartment; it does not acquire permission to read the widget's cookie. SameSite=None is included so that our accepted cross-site exchanges are not defeated by that particular filter. It does not tell the browser to search every partition for a matching name.

The fixed attributes are host-only, Path=/panel, Secure, HttpOnly, explicit SameSite=None and Partitioned. Secure and HttpOnly constrain transport and non-HTTP access, while CHIPS adds top-level-site partitioning and requires Secure. [1][3] For this direct-child example, use the explanatory key K=(widget.example.net, /panel, panel_mode, top-level schemeful site). This is not presented as the complete Chromium key or a universal browser database schema; the model does not exercise nested cross-site ancestry or additional implementation-specific selectors.

Under A, K ends in (HTTPS, example.com); under the news context B, it ends in (HTTPS, example.org). The cookie remains associated with the widget host in both records. The top-level site's contribution to selection does not transfer cookie ownership to that site's scripts. Explicit SameSite=None removes the Strict/Lax cross-site restriction from the stipulated request comparison, but other cookie and browser rules still apply. [6] It does not erase the Partitioned attribute or cause the browser to substitute a value from another top-level-site key.

Start with an empty model store. While embedded under the shopping site A, the widget receives an accepted write setting panel_mode to compact. There is now one record. Visit the news site B, which embeds the same widget host and path. B selects a different top-level-site compartment, so its first request has no value from this model. Nothing has deleted compact. The request simply did not select the record that contains it. This follows the separation described in the CHIPS documentation. [1]

Now set wide while the widget is under B. The store contains two records: compact for the example.com partition and wide for example.org. Both share the same cookie name, host and path. Returning to A still selects compact. The key distinction is between replacing the value at an existing full key and creating a value at another key. Counting names alone would report one name; counting records reports two. Neither count, without its definition, fully explains what the next embedded request can remember.

Begin with an empty finite map. The first accepted write stores compact at K_A. Before any B write, lookup(K_B) is absent because K_B differs in its top-level-site component, even though host, path and name match. This is an original state trace of the CHIPS partition relationship. [1] The absent lookup is not equivalent to a deletion event at K_A, nor is it an empty string stored at K_B. Those three states have different histories despite potentially similar visible default layouts.

The second accepted write stores wide at K_B, increasing the map from one record to two. A subsequent lookup at K_A still yields compact. Keeping the identity tuple explicit prevents a name-based replacement rule from crossing the partition boundary in the explanation. RFC 6265 supplies the underlying replacement and scope concepts; the Google documentation supplies the additional partition relationship. [1][3] The example does not infer how many other cookies exist, how the values are serialized internally, or whether a browser retains them beyond the stipulated sequence.

Open the widget inside https://learn.example.com:8443/course. This surrounding page has a different origin from the shopping page, but their schemeful sites are equal. [2] Our model therefore selects the existing example.com compartment and reads compact. [1] The different host and visible port are not enough to produce another partition here. This is a useful counterexample to the tempting rule that every different-looking page gets an entirely separate copy of embedded state.

Next, return to the shopping page and change its layout preference to roomy. That write replaces compact at the same full key, so the number of stored records remains two. The learning page now reads roomy because it selects that key too. The news page still reads wide. One changed preference has affected two surrounding origins without affecting the other schemeful site. This is not an exception to partitioning: it is the consequence of choosing the site, rather than the full top-level origin, as the selector in this example.

A-sibling and A have unequal ordinary origins but equal schemeful sites. [2] Given the unchanged widget host, path, name and other fixed attributes, K_A-sibling=K_A in the direct-child CHIPS fixture. [1] A read from the sibling context therefore returns compact rather than an absent value. Treating the top-level origin as the partition key would incorrectly predict a third record and would hide the actual grouping relation the documented mechanism uses.

Assign roomy to K_A. This is an update, not an insertion: map cardinality remains two. Lookups from A and A-sibling both return roomy, while lookup(K_B) remains wide. The trace separates equality of selectors from equality of page origins and from equality of stored values. Two unequal keys could coincidentally hold the same string, so observing equal layouts would not prove shared storage either. Here we know why the values agree because the hypothetical writes and keys are explicit, rather than inferred from visual similarity alone.

Now visit https://widget.example.net/panel as the main page itself. The top-level schemeful site is https://example.net, not example.com or example.org. Google's CHIPS example likewise distinguishes a service's direct top-level visit from the compartments it used when embedded under other sites. [1] In our trace, the first direct visit finds no panel_mode value at this new key. The shopping and news preferences remain stored, but neither becomes the direct visit's preference just because the widget host is the same.

Set plain during that direct visit. There are now three records: roomy for example.com, wide for example.org and plain for example.net, all under HTTPS. A return to the learning page still gives roomy; the news page still gives wide. The direct visit has not joined or copied the earlier compartments. This final inventory is more informative than saying the service remembers three choices: it states which context selects each choice, and it shows why a perfectly successful write can remain invisible in another context.

When the widget becomes the top-level document, the partition site changes to (HTTPS, example.net). Its own request host remains widget.example.net, so the changed selector is the partition component rather than the host component. Google's documented CHIPS flow explains this direct-visit separation. [1] In the finite map, K_service is unequal to both K_A and K_B. Its initial absence therefore says nothing about the continued existence of either earlier record.

Writing plain at K_service increases cardinality to three. The final mapping is K_A→roomy, K_B→wide and K_service→plain, with A-sibling selecting K_A. The four surrounding-page contexts thus refer to three modeled records. This explicit many-context-to-one-key relation is the reason origin counts, site counts and cookie-record counts must not be substituted for one another. A direct visit may have other application behavior in a real service, but none is needed or assumed for the partition-selection result derived here.

Our widget can show roomy even though its page script cannot read the HttpOnly preference through ordinary script cookie access. The browser can send the applicable cookie in an HTTP request, and the server can use its value when building the response. HttpOnly restricts non-HTTP access; it does not mean the cookie is withheld from every HTTP request. [3] In this example, the visible layout is a result of that server response. It is not evidence that the shopping page or the widget's JavaScript read the protected cookie directly.

An ordinary Cookie request header carries names and values, not a complete description of the stored records. RFC 6265 explains that attributes such as Path, Secure and expiry are not returned in that header. [3] Seeing panel_mode=roomy on one request therefore does not reveal the whole partition inventory or explain the earlier writes. A useful record of the observation also needs the surrounding site, request destination and relevant attributes. Otherwise the same short header can be attached to several incompatible stories about how the browser selected it.

HttpOnly is a non-HTTP access restriction, distinct from Secure's transport condition and the partition selector. RFC 6265 describes those flags independently. [3] In our model, the server interprets the Cookie header and renders the selected layout; document.cookie is not used to retrieve panel_mode. This avoids a common explanatory inconsistency in which a diagram labels a cookie HttpOnly while the prose has client-side script directly read that same value. The response can expose an application result without exposing the cookie through that API.

Cookie request serialization supplies name/value pairs rather than all stored attributes. [3] A captured panel_mode=roomy string, considered alone, is therefore not a storage-key dump. It does not specify the top-level site, the path used for matching, the earlier replacement event or how many other partitions hold the same name. In the worked trace those facts come from the separately defined context and state map. The distinction is between observing a selected value on an exchange and reconstructing the entire state that could have produced it.

For a separate comparison, imagine valid, already stored unpartitioned cookies created during an earlier first-party visit, with explicit Strict, Lax or None settings. Use the recorded rules of IETF draft 22, dated 1 December 2025 and carrying an expiry of 4 June 2026; it is a work-in-progress snapshot, not a final RFC or a browser compatibility test. [6] With other restrictions held satisfied, all three pass the SameSite filter for a same-site HTTP request. A cross-site embedded GET passes that filter only with None.

For a cross-site top-level navigation using the safe GET method, Lax and None pass this filter; Strict does not. For a cross-site top-level POST, only None passes in this explicit-setting example. [6] Passing is not a guarantee of delivery. We deliberately start with valid stored cookies because the same draft rejects Strict/Lax creation through cross-site subresource responses or nested navigations. [6] This table is not an instruction to create those cookies inside our widget. Its separate unpartitioned records also do not change the three partitioned preferences already traced.

The separate SameSite fixture uses valid pre-existing unpartitioned cookies with explicit Strict, Lax or None flags and all other retrieval conditions satisfied. The source is pinned IETF draft-ietf-httpbis-rfc6265bis-22, dated 1 December 2025, with stated expiry 4 June 2026; it is not presented as a final RFC or current universal implementation contract. [6] Its cross-site exception for Lax requires an HTTP retrieval, a safe method and a top-level navigation. The native complete condition list, not a shortened extracted list, governs this comparison.

The resulting rows for Strict/Lax/None are: same-site HTTP, pass/pass/pass; cross-site iframe GET, fail/fail/pass; cross-site top-level GET, fail/pass/pass; cross-site top-level POST, fail/fail/pass. [6] Explicit flags exclude the draft's optional default-mode Lax-allowing-unsafe behavior. Creation is a separate gate: Strict/Lax cannot be set through cross-site subresource responses or nested navigations under the cited rule. [6] Hence the earlier first-party creation premise. No partition is merged by this table, and a pass means only that this filter permits selection; other policies may still prevent sending.

A browser's wider privacy feature is not necessarily the same mechanism as a cookie explicitly opting into CHIPS. Google documents CHIPS support from Chrome 114, while Mozilla describes its own state-partitioning system and says it became the default for Firefox users from version 103. [1][4] Mozilla also discusses exceptions and transitional compatibility heuristics. [4] Those are scoped implementation descriptions. They are a reason to record the browser and version when investigating behavior, not a basis for assuming every browser setting creates exactly our three-record model.

The Storage Access API addresses access to unpartitioned state in certain embedded situations. Its retrieved document is a Draft Community Group Report dated 26 October 2026, and it explicitly says it is neither a WHATWG Living Standard nor a W3C standards-track document. [5] It distinguishes checking access from requesting it, leaves room for browser grant decisions and warns that an overall granted state does not ensure every outgoing request includes an unpartitioned cookie. [5] Asking for access is therefore not the same as automatically merging our partitioned choices into a shared preference.

CHIPS is an explicit cookie attribute mechanism in Google's documentation; Mozilla's state-partitioning guide describes a broader browser policy and its Firefox 103 default rollout. [1][4] The latter's origin-oriented discussion of partitioned state is not substituted for the host/name/path semantics of our cookie fixture. The guide also documents exceptions and transitional heuristics. [4] These differences limit what can be deduced from a generic setting label: the effective implementation, version, context and grant state remain relevant.

The retrieved Storage Access API text is the 26 October 2026 Draft Community Group Report, explicitly outside both WHATWG Living Standard and W3C standards-track status. [5] Its hasStorageAccess and requestStorageAccess operations concern unpartitioned access under defined context and permission conditions. Granting remains implementation-dependent in part, and the text distinguishes an overall permission state from whether a particular document or request is eligible. [5] Neither an API name nor a successful permission classification demonstrates that partitioned and unpartitioned stores have been unified, or that every request can carry every stored cookie.

Return to the final three-record map and perform one additional hypothetical operation: delete only the exact example.com partition record. The shopping and learning contexts now lack their preference, while the news context keeps wide and the service's direct visit keeps plain. Two records remain. This is a deliberately specified deletion, not a claim about what a particular browser's clear-data button removes. Its purpose is to show why the scope of an operation must be known before interpreting a changed layout.

A missing value on a request can have several different explanations in the documented mechanisms: the selected key may lack a record, a cookie may have expired or been removed, or matching and browser policy may prevent it being sent. [1][3][6] The visible symptom alone cannot decide among them. Nor does partitioning establish complete anonymity: the IETF draft notes that cookies are not the only way to correlate users across sites. [6] A precise observation describes the missing value and its context without turning it into a claim that every other record or identification route has disappeared.

Apply a deletion to K_A only in the final finite map. K_A-sibling is the same key, so both surrounding contexts now produce absence. K_B and K_service remain mapped to wide and plain, giving cardinality two. This operation is defined over one exact modeled key. No browser user-interface clearing scope, server logout behavior or cross-device effect is inferred. Enumerating any subset of the three independent keys simply leaves three minus the number of deleted keys in this fixed map.

Observation and cause remain distinct. Absence from a particular request is compatible with no record at the selected partition, expiry or eviction, host/path mismatch, a request filter, or an additional browser restriction. [1][3][6] The earlier accepted-write assumptions remove those alternatives only within the constructed trace. They do not remove them from an actual investigation. Finally, isolation of selected cookie state is narrower than prevention of every cross-site correlation technique; the cited draft explicitly distinguishes cookies from other tracking mechanisms. [6] That boundary prevents a correct storage explanation from becoming an unsupported privacy guarantee.

A useful explanation of a remembered choice starts with a short record: the surrounding page URL, the embedded request's host and path, the cookie's name and attributes, and whether the observation concerns a write, a request value or a rendered response. Those fields correspond to different parts of the documented identity and matching rules. [1][2][3] They should not be collapsed into a single statement that the site allowed or blocked cookies. In our example, writing wide under the news site was successful even while the shopping site continued showing another value.

Then ask which change would actually alter the explanation. A sibling top-level origin may keep the same site key. A direct visit to the service changes that key. A SameSite setting can change request eligibility without changing an existing record's partition identity. [1][2][6] Browser-specific policies and access grants require their own evidence. [4][5] This sequence gives the reader a way to interpret apparently inconsistent preferences: keep the storage selector, the request conditions and the observed result separate, and claim only what their documented relationship can establish.

A reproducible interpretation should distinguish the top-level origin from its schemeful site, preserve the cookie's host/name/path and attributes, and identify the request or write being discussed. [1][2][3] Record whether the evidence is a stored-record view, a serialized Cookie header or an application response, because those observations expose different information. In the original trace, the same request host and name support three final values, while four top-level contexts map onto only three records. The full context resolves the apparent inconsistency.

For each proposed setting change, identify its actual mechanism: record partition, cookie matching, SameSite eligibility or browser-specific access policy. [1][3][4][5][6] Do not infer one mechanism from another's label. The finite cases show both directions of the error: different origins can select one partition, while one widget host can select different partitions. Keeping those relations explicit is more useful than describing the browser as simply remembering or forgetting. It also makes an unresolved case visible: without the relevant context and policy state, a missing value cannot uniquely identify the cause.