diff --git a/README.md b/README.md
index 301332e..ad1f33a 100644
--- a/README.md
+++ b/README.md
@@ -774,7 +774,7 @@ Related origins can still deduplicate downloads themselves, with Web Locks, a `B
 A `CrossOriginStorageManager` uses the origin of its context. For a worker, that is the origin of the worker's environment settings object, independent of its script URL:
 
 - **Workers created from a `blob:` URL** have the origin of the context that created them and share that page's COS view: each reads what the other stored, and the worker's writes count as the page's own. Revoking the `blob:` URL does not change this.
-- **Workers created from a `data:` URL** have an opaque origin, which has no stable identity to key storing origins or same-site checks on. This proposal does not yet define what `getFileHandle()` does for an opaque calling origin; the opaque-origin rule in "validate a COS request" covers only the origins a caller names in `origins`. Implementations should at minimum reject such calls promptly, so the returned promise never stays pending.
+- **Workers created from a `data:` URL** have an opaque origin, which has no stable identity to key storing origins or same-site checks on. `getFileHandle()` therefore rejects with a `NotAllowedError` when the calling origin is opaque, as it also does for a sandboxed `<iframe>` without `allow-same-origin`. This is separate from the opaque-origin rule in "validate a COS request", which covers only the origins a caller names in `origins`.
 - **Service workers** cannot use COS for now; see below.
 
 The Permissions Policy check applies to the calling global. A dedicated or shared worker may use COS only if every document in its owner set may, resolved transitively through any intervening workers, so `Permissions-Policy: cross-origin-storage=()` also covers calls moved into `new Worker(URL.createObjectURL(blob))`. A service worker has no owner set: its registration persists, and the browser starts it in response to events, often with no client open. Supporting service workers needs a policy captured from their own script response, most plausibly a `Permissions-Policy` header, which is work for the Permissions Policy and Service Workers specifications.
@@ -900,6 +900,7 @@ Mitigations need to carefully balance between ensuring the user's privacy and ma
 * Every lookup that could reveal what another site stored, whether it finds the file or not, counts against a small budget of cross-site lookups, on the order of 8 to 16 per time window, both budget and time window defined by the user agent. Lookups for files the requesting site stored itself stay free. The budget belongs to the top-level site the user is visiting (its scheme and registrable domain), and every frame on the page draws from it, so a tracker cannot multiply it by adding origins or by moving the page through subdomains of one site.
 * A written file becomes shareable with other sites only after a user gesture on the page, while the page itself can use the file right away. This is to prevent writes during silent reloads of the page.
 * The count persists across page reloads for the whole top-level site (and across tabs), so reloading does not reset it.
+* Only a clearing of site data that the user asks for, through the browser's own settings or storage UI, resets the count. A clearing the site requests itself, for example with the `Clear-Site-Data` header, leaves it untouched, since a site could otherwise clear its own data between lookups and draw an unbounded number of them.
 * Each call to `getFileHandle()` can further be limited for sites known to be malicious, for example, from Safe Browsing.
 
 Since each lookup reveals at most one bit, a budget of 8 limits a tracker to 8 bits per window, well short of the roughly 32 bits needed to identify a device. A patient tracker can still combine partial results over time, so cross-site tracking becomes slow and paced by the user's own engagement, but not impossible.
diff --git a/index.bs b/index.bs
index 7a0ba73..101b72b 100644
--- a/index.bs
+++ b/index.bs
@@ -272,12 +272,10 @@ script itself, has a consequence worth spelling out for workers. A worker create
 Cross-Origin Storage view exactly: what such a worker writes, its creating page can read back, and
 what the page stored, the worker can read. The `blob:` URL is not an origin of its own, and
 revoking it does not detach the worker from that view. A worker created from a `data:` URL
-has an [=opaque origin=]. This specification does not currently define what
-{{CrossOriginStorageManager/getFileHandle()}} does when the <em>calling</em> origin is opaque;
-the [=opaque origin=] rule in [=validate a COS request=] governs only the origins a
-caller <em>names</em>. An opaque origin has no stable identity to key
-[=COS entry/storing origins=] or [=same site=] comparisons on, so there is nothing meaningful for
-it to be granted.
+has an [=opaque origin=], and {{CrossOriginStorageManager/getFileHandle()}} rejects when the
+<em>calling</em> origin is opaque; see [[#getfilehandle]]. This is separate from the
+[=opaque origin=] rule in [=validate a COS request=], which governs only the origins a caller
+<em>names</em>.
 
 ## The {{CrossOriginStorageManager/getFileHandle()}} method ## {#getfilehandle}
 
@@ -316,6 +314,16 @@ steps are:
 1. Let |realm| be [=this=]'s [=relevant Realm=].
 1. Let |global| be [=this=]'s [=relevant global object=].
 1. Let |origin| be [=this=]'s associated [=/origin=].
+1. If |origin| is an [=opaque origin=], then:
+   1. [=Queue a global task=] on the [=DOM manipulation task source=] given |global| to
+      [=/reject=] |result| with a "{{NotAllowedError}}" {{DOMException}}.
+   1. Return |result|.
+
+   Note: A context with an [=opaque origin=], such as a sandboxed <{iframe}> without
+   `allow-same-origin` or a worker created from a `data:` URL, has no stable identity, and each
+   such context gets a fresh one. [=COS entry/storing origins=] membership and the [=same site=]
+   comparison behind the default scope both key on the calling origin, so there is nothing
+   meaningful to grant such a context.
 1. If the result of running [=check Cross-Origin Storage permission=] given |global| is
    false, then:
    1. [=Queue a global task=] on the [=DOM manipulation task source=] given |global| to
@@ -1389,7 +1397,10 @@ PHL-eligible resources by choosing which subset to write. A user agent that bloc
 cookies can still offer the "`*`" grant if it bounds cross-site disclosure, for example with a
 small budget of cross-site lookups keyed on the top-level site and shared by every frame on
 the page, a count that persists across reloads for a time window, and sharing of written entries only
-after a user gesture. The README's
+after a user gesture. Such a count bounds disclosure only if the site cannot reset it, so a
+clearing of site data that the site requests itself, for example with the `Clear-Site-Data`
+header [[CLEAR-SITE-DATA]], has to leave it untouched, and only a clearing the user asks for
+through the user agent's own settings resets it. The README's
 [privacy considerations](README.md#privacy-considerations) describe these mitigations.
 
 ## GREASE'ing ## {#greaseing}