security: announce a fresh EIP-6963 provider UUID per page load (closes #398)

The provider UUID was generated once, stored in extension storage, and
announced verbatim to every page on every load and across restarts, so any
site — connected or not — could read a stable cross-site, cross-session
identifier for the install: a supercookie contradicting the "no tracking"
promise. EIP-6963 wants a fresh UUIDv4 per announcement instead.

inpage.js now announces a per-load crypto.randomUUID() and persists nothing;
the eip6963Uuid storage key and the AUTISTMASK_PROVIDER_UUID content-script
message are removed. That key was a standalone top-level storage entry, never
part of the versioned autistmask profile, so stateSchema.js and the
persisted-field harness are untouched and no existing profile is affected.

A jest test asserts two loads announce different UUIDv4s and that one load
reuses a single UUID across re-announcements.

Model: opus-4-8

TODO.md

@@ -132,6 +132,28 @@ but the review is broader than any of them.
   constant rather than `isDebug()`, so it survives only in a debug build; a
   testnet or the runtime debug toggle still raises the banner but without the
   view id.
+
+- 2026-09-21: The Confirm Delete button on the delete-wallet screen no longer
+  stays dead after a successful delete
+  ([#335](https://git.eeqj.de/sneak/AutistMask/issues/335)). The password route
+  disabled the button before the decrypt and never re-enabled it, so a second
+  delete in the same popup session needed a reopen; the lost-password route
+  re-enabled its own button in its leave hook, so the two screens behaved
+  differently. Both now reset through the shared `finishDelete()`, the one path
+  both routes take, so they behave the same and the button is live for the next
+  delete.
+
+- 2026-09-21: The EIP-6963 provider UUID is generated fresh on each page load
+  and never persisted ([#398](https://git.eeqj.de/sneak/AutistMask/issues/398)).
+  It was created once and stored, then announced verbatim to every page on every
+  load and across restarts, so any site — connected or not — could read it as a
+  stable cross-site, cross-session identifier for the install, contradicting the
+  "no tracking" promise. inpage.js now announces a per-load
+  `crypto.randomUUID()` and the `eip6963Uuid` storage key and the
+  `AUTISTMASK_PROVIDER_UUID` content-script message are gone. That key was a
+  standalone storage entry, never part of the versioned `autistmask` profile, so
+  the state schema is untouched and no existing profile is affected.
+
 - 2026-08-30: An address no longer wraps, or is shortened to fit, in any of the
   common views ([#380](https://git.eeqj.de/sneak/AutistMask/issues/380)). The
   wallet list was the reported case: the address shared one row with the

src/content/index.js

@@ -5,8 +5,6 @@ const {
     hasBrowserNamespace,
     runtimeApi,
     sendMessage,
-    storageGet,
-    storageSet,
 } = require("../shared/browserApi");
 
 // In Chrome (MV3), inpage.js runs as a MAIN-world content script declared
@@ -21,30 +19,6 @@ if (hasBrowserNamespace()) {
     (document.head || document.documentElement).appendChild(script);
 }
 
-// Send the persisted EIP-6963 provider UUID to the inpage script.
-// Generated once at install time and stored in extension storage.
-(async function sendProviderUuid() {
-    let uuid = null;
-    try {
-        const items = await storageGet("eip6963Uuid");
-        uuid = items?.eip6963Uuid;
-        if (!uuid) {
-            uuid = crypto.randomUUID();
-            await storageSet({ eip6963Uuid: uuid });
-        }
-    } catch {
-        // Storage was unavailable or refused the write. The announcement
-        // still has to go out — a provider that never announces is invisible
-        // to every EIP-6963 dApp — so it goes under a fresh uuid that this
-        // page load will not outlive.
-        if (!uuid) uuid = crypto.randomUUID();
-    }
-    window.postMessage(
-        { type: "AUTISTMASK_PROVIDER_UUID", uuid },
-        location.origin,
-    );
-})();
-
 // Relay requests from the page to the background script
 window.addEventListener("message", (event) => {
     if (event.source !== window) return;

src/content/inpage.js

@@ -204,7 +204,14 @@
                 "</svg>",
         );
 
-    let providerUuid = crypto.randomUUID(); // fallback until real UUID arrives
+    // EIP-6963 wants a fresh UUIDv4 per page load — it identifies one
+    // announcement, so a provider can be told apart from another instance of
+    // itself in the same page. It is generated here and never stored:
+    // announcing one persisted value to every site, on every load and across
+    // restarts, turned it into a stable cross-site, cross-session tracking
+    // identifier any page could read
+    // (https://git.eeqj.de/sneak/AutistMask/issues/398).
+    const providerUuid = crypto.randomUUID();
 
     function buildProviderInfo() {
         return {
@@ -226,16 +233,6 @@
         );
     }
 
-    // Listen for the persisted UUID from the content script
-    function onProviderUuid(event) {
-        if (event.source !== window) return;
-        if (event.data?.type !== "AUTISTMASK_PROVIDER_UUID") return;
-        window.removeEventListener("message", onProviderUuid);
-        providerUuid = event.data.uuid;
-        announceProvider();
-    }
-    window.addEventListener("message", onProviderUuid);
-
     window.addEventListener("eip6963:requestProvider", announceProvider);
     announceProvider();
 

src/popup/views/deleteWallet.js

@@ -51,16 +51,12 @@ function clear() {
 // The lost-password screen holds no secret — a wallet name is not one —
 // but it is wiped on leave for the neighbouring reason: a typed
 // confirmation left standing in a hidden view is one click away from
-// destroying a wallet the user has since navigated off. The button is
-// re-enabled here too, so a screen left mid-delete is usable on re-entry.
+// destroying a wallet the user has since navigated off.
 function clearLostPassword() {
     lostPasswordIndex = null;
     $("delete-wallet-lost-name-input").value = "";
     $("delete-wallet-lost-flash").textContent = "";
     $("delete-wallet-lost-flash").style.visibility = "hidden";
-    const btn = $("btn-delete-wallet-lost-confirm");
-    btn.disabled = false;
-    btn.classList.remove("text-muted");
 }
 
 function show(walletIdx) {
@@ -98,6 +94,17 @@ function showLostPassword() {
 // cleanup and the accountsChanged broadcast cannot drift apart between
 // them.
 async function finishDelete(walletIdx) {
+    // Each route's confirm button was disabled by its own click handler
+    // before the delete ran. Re-enable both here, on the one path they
+    // share, so the two routes reset the same way and a second delete in
+    // the same popup session finds a live button instead of a dead one.
+    const passwordBtn = $("btn-delete-wallet-confirm");
+    passwordBtn.disabled = false;
+    passwordBtn.classList.remove("text-muted");
+    const lostPasswordBtn = $("btn-delete-wallet-lost-confirm");
+    lostPasswordBtn.disabled = false;
+    lostPasswordBtn.classList.remove("text-muted");
+
     const { activeAddressChanged } = removeWalletFromState(state, walletIdx);
 
     deleteWalletIndex = null;
@@ -187,8 +194,8 @@ function init(_ctx) {
         btn.disabled = true;
         btn.classList.add("text-muted");
 
-        // finishDelete() navigates, and the leave hook re-enables the
-        // button and wipes the typed name on the way out.
+        // finishDelete() re-enables the button; navigating away then runs
+        // the leave hook that wipes the typed name.
         await finishDelete(lostPasswordIndex);
     });
 

tests/deleteWalletLostPassword.test.js

@@ -172,6 +172,15 @@ async function openLostPassword(deleteWallet, walletIdx) {
     await click("btn-delete-wallet-lost-password");
 }
 
+// Delete a wallet through the password route: open its confirm screen,
+// enter the password, and confirm. The vault is mocked, so the password
+// text itself is irrelevant — decryptWithPassword decides pass or fail.
+async function deleteWithPassword(deleteWallet, walletIdx) {
+    deleteWallet.show(walletIdx);
+    node("delete-wallet-password").value = "any password";
+    await click("btn-delete-wallet-confirm");
+}
+
 // ------------------------------------------------------------ tests
 
 // The stub is what every persistence assertion below rests on, so its one
@@ -456,15 +465,21 @@ describe("what the screen leaves behind", () => {
         );
     });
 
-    // Left mid-delete, the screen has to come back usable.
-    test("the confirm button is re-enabled on the way out", async () => {
-        const { helpers, deleteWallet } = load();
+    // Both routes now re-enable through finishDelete(), not their leave
+    // hooks, so the button comes back live once a delete completes.
+    test("the confirm button is re-enabled after a delete", async () => {
+        const { deleteWallet } = load();
         await openLostPassword(deleteWallet, 1);
 
-        node("btn-delete-wallet-lost-confirm").disabled = true;
-        helpers.showView("settings");
+        node("delete-wallet-lost-name-input").value = "Wallet 2";
+        await click("btn-delete-wallet-lost-confirm");
 
         expect(node("btn-delete-wallet-lost-confirm").disabled).toBe(false);
+        expect(
+            node("btn-delete-wallet-lost-confirm").classList.contains(
+                "text-muted",
+            ),
+        ).toBe(false);
     });
 
     // A wallet name is not a secret, so the screen is excluded for the
@@ -475,3 +490,48 @@ describe("what the screen leaves behind", () => {
         expect(RESTORABLE_VIEWS.has("delete-wallet-confirm")).toBe(false);
     });
 });
+
+// The password route is the pre-existing bug this file's fix addresses:
+// its Confirm Delete button was disabled before the decrypt and never
+// re-enabled on success, so a second delete in the same popup session
+// found a dead button. Now both routes re-enable through finishDelete().
+//
+// Against head these tests fail: with the re-enable absent, the button
+// stays disabled after the first delete, so the disabled assertions read
+// true where they expect false.
+describe("the password route's confirm button", () => {
+    test("is re-enabled after a successful delete", async () => {
+        const { deleteWallet, vault } = load();
+        vault.decryptWithPassword.mockResolvedValue();
+
+        await deleteWithPassword(deleteWallet, 1);
+
+        expect(node("btn-delete-wallet-confirm").disabled).toBe(false);
+        expect(
+            node("btn-delete-wallet-confirm").classList.contains("text-muted"),
+        ).toBe(false);
+    });
+
+    // The reported symptom: delete one wallet, then open Delete Wallet for
+    // a second one without reopening the popup. The button must be live on
+    // that second visit, and the second delete must actually persist.
+    test("a second delete works in the same popup session", async () => {
+        const { deleteWallet, vault, storage } = load();
+        vault.decryptWithPassword.mockResolvedValue();
+
+        await deleteWithPassword(deleteWallet, 1);
+
+        // Wallet 2 is gone; the list is now [Wallet 1, Wallet 3]. Opening
+        // the confirm screen for the wallet now at index 1 (Wallet 3) must
+        // find its button live, not the dead one the first delete left.
+        deleteWallet.show(1);
+        expect(node("btn-delete-wallet-confirm").disabled).toBe(false);
+
+        node("delete-wallet-password").value = "any password";
+        await click("btn-delete-wallet-confirm");
+
+        expect((await persistedWallets(storage)).map((w) => w.name)).toEqual([
+            "Wallet 1",
+        ]);
+    });
+});

tests/e2e/firefox/run.js

@@ -372,10 +372,10 @@ step("the loopback dApp page gets the real inpage provider", async (env) => {
         STEP_TIMEOUT_MS,
     );
 
-    // EIP-6963, asked of the provider itself. The announcement carries the
-    // uuid src/content/index.js reads out of extension storage — call site 1
-    // in the issue — and it has to name this extension and hand back the very
-    // object on window.ethereum.
+    // EIP-6963, asked of the provider itself. The announcement carries a
+    // UUIDv4 inpage.js generates fresh for this page load (nothing persists
+    // it — see issue #398) and has to name this extension and hand back the
+    // very object on window.ethereum.
     const announced = await d.executeAsync(
         `const done = arguments[arguments.length - 1];
          const onAnnounce = (e) => {
@@ -402,7 +402,7 @@ step("the loopback dApp page gets the real inpage provider", async (env) => {
     );
     assert(
         typeof announced.uuid === "string" && announced.uuid.length === 36,
-        "the announcement carries no stored provider uuid: " +
+        "the announcement carries no provider uuid: " +
             JSON.stringify(announced.uuid),
     );
 

tests/inpageProviderUuid.test.js

@@ -0,0 +1,103 @@
+// The EIP-6963 provider UUID inpage.js announces (src/content/inpage.js).
+//
+// The bug this pins down (issue #398): the UUID used to be generated once,
+// persisted in extension storage, and announced verbatim to every page on
+// every load and across browser restarts, so any site — connected or not —
+// could read a stable cross-site, cross-session identifier for the install.
+// EIP-6963 wants a fresh UUIDv4 per announcement instead. The fix generates
+// it per page load and stores nothing.
+//
+// inpage.js is a bare IIFE injected into the page's JS context, not a module;
+// see tests/inpageErrors.test.js for why it is evaluated against a stub window
+// rather than imported. Here the stub captures the CustomEvent that carries
+// the announcement, so the UUID this file reads is the one a real dApp's
+// eip6963:announceProvider listener would see.
+
+const fs = require("fs");
+const path = require("path");
+const { webcrypto } = require("crypto");
+
+const SOURCE = fs.readFileSync(
+    path.join(__dirname, "..", "src", "content", "inpage.js"),
+    "utf8",
+);
+
+const loadInto = new Function(
+    "window",
+    "self",
+    "crypto",
+    "Event",
+    "CustomEvent",
+    SOURCE,
+);
+
+class StubEvent {
+    constructor(type) {
+        this.type = type;
+    }
+}
+
+class StubCustomEvent extends StubEvent {
+    constructor(type, init) {
+        super(type);
+        this.detail = init && init.detail;
+    }
+}
+
+// Evaluate inpage.js once against a fresh stub window and return every UUID it
+// announced. A `requestProvider` event is dispatched too, so a re-announcement
+// within one load is observed as well as the announcement at load.
+function announcedUuids() {
+    const listeners = {};
+    const uuids = [];
+
+    const win = {
+        addEventListener(type, fn) {
+            (listeners[type] || (listeners[type] = [])).push(fn);
+        },
+        removeEventListener(type, fn) {
+            const fns = listeners[type];
+            if (!fns) return;
+            const i = fns.indexOf(fn);
+            if (i !== -1) fns.splice(i, 1);
+        },
+        postMessage() {},
+        dispatchEvent(event) {
+            if (event.type === "eip6963:announceProvider") {
+                uuids.push(event.detail.info.uuid);
+            }
+            for (const fn of (listeners[event.type] || []).slice()) fn(event);
+            return true;
+        },
+    };
+    win.window = win;
+
+    loadInto(win, win, webcrypto, StubEvent, StubCustomEvent);
+    win.dispatchEvent(new StubEvent("eip6963:requestProvider"));
+    return uuids;
+}
+
+const UUID_V4 =
+    /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/;
+
+describe("the EIP-6963 provider UUID is fresh per page load", () => {
+    test("a load announces a UUIDv4, unprompted, with nothing delivered", () => {
+        const uuids = announcedUuids();
+        expect(uuids.length).toBeGreaterThan(0);
+        expect(uuids[0]).toMatch(UUID_V4);
+    });
+
+    test("every announcement within one load carries the same UUID", () => {
+        const uuids = announcedUuids();
+        expect(uuids.length).toBeGreaterThan(1);
+        expect(new Set(uuids).size).toBe(1);
+    });
+
+    test("two page loads announce different UUIDs", () => {
+        const first = announcedUuids()[0];
+        const second = announcedUuids()[0];
+        expect(first).toMatch(UUID_V4);
+        expect(second).toMatch(UUID_V4);
+        expect(second).not.toBe(first);
+    });
+});