harden: connectedSites is never cleared for a removed address or wallet #245

New Issue

2026-08-12T10:25:15+02:00

clawbot commented

2026-08-12 10:25:15 +02:00

The background keeps an in-memory connectedSites map keyed origin + ":" + address. Nothing clears an entry when the address it names stops existing.

removeWalletFromState() has never cleared it, and the address-level removal added by #240 does not either — so this is pre-existing and consistent, not a regression introduced there. Found by the independent review of that PR and filed rather than dropped.

Both removal paths already drop the persisted allowedSites / deniedSites for the address. The in-memory map is the one piece of connection state that survives, so for the life of the service worker a dApp can still be treated as connected to an address the user deleted.

Implementation requirements

Clear connectedSites entries for the removed address on both the wallet-level and address-level removal paths, alongside the existing dropSitePermissions call.
Check what connectedSites actually gates before choosing the fix — if a stale entry only affects an accountsChanged emission, the consequence is different from it gating an approval, and the PR body should say which it is.
Confirm whether the map is rebuilt from storage on service-worker restart. If it is, the exposure window is bounded by the worker lifetime and that bound should be stated; if it is not, say so.

Definition of done

Removing an address clears its connectedSites entries; removing a wallet clears them for every address it held.
A test drives a removal with a live connected site and asserts the entry is gone.
The PR body states what connectedSites gates and the exposure window before the fix.
TODO.md updated in the same commit.
make check passes.

The background keeps an in-memory `connectedSites` map keyed `origin + ":" + address`. Nothing clears an entry when the address it names stops existing. `removeWalletFromState()` has never cleared it, and the address-level removal added by https://git.eeqj.de/sneak/AutistMask/pulls/240 does not either — so this is pre-existing and consistent, not a regression introduced there. Found by the independent review of that PR and filed rather than dropped. Both removal paths already drop the persisted `allowedSites` / `deniedSites` for the address. The in-memory map is the one piece of connection state that survives, so for the life of the service worker a dApp can still be treated as connected to an address the user deleted. ## Implementation requirements - Clear `connectedSites` entries for the removed address on both the wallet-level and address-level removal paths, alongside the existing `dropSitePermissions` call. - Check what `connectedSites` actually gates before choosing the fix — if a stale entry only affects an `accountsChanged` emission, the consequence is different from it gating an approval, and the PR body should say which it is. - Confirm whether the map is rebuilt from storage on service-worker restart. If it is, the exposure window is bounded by the worker lifetime and that bound should be stated; if it is not, say so. ## Definition of done - [ ] Removing an address clears its `connectedSites` entries; removing a wallet clears them for every address it held. - [ ] A test drives a removal with a live connected site and asserts the entry is gone. - [ ] The PR body states what `connectedSites` gates and the exposure window before the fix. - [ ] `TODO.md` updated in the same commit. - [ ] `make check` passes.

clawbot referenced this issue

2026-08-12 10:56:22 +02:00

feat: remove an address from an HD wallet, behind a confirmation (closes #162) #240

clawbot referenced this issue

2026-09-21 09:19:59 +02:00

Review toward 1.0: identify and file all next steps #382

clawbot added this to the 1.0.0 milestone 2026-09-21 09:20:00 +02:00

clawbot referenced this issue

2026-09-21 20:37:56 +02:00

harden: a session (non-remembered) site connection cannot be revoked from the UI, and the remove-site message does nothing #406

clawbot commented

2026-10-03 14:18:55 +02:00

Plan. One PR on a branch cut from next, base next, following the implementation requirements above.

Clear the background's connectedSites entries for a removed address on the address-level and wallet-level removal paths, next to the existing dropSitePermissions call; one small shared helper, not two copies.
A unit test drives each removal with a live connected site and asserts the entry is gone; it must fail against current next.
The PR body states, from the code, what connectedSites gates and whether it survives a service-worker restart.
Kept separate from #406 (revoking a session connection), which touches the same map and follows this unit.

Model: opus-5-5

Plan. One PR on a branch cut from `next`, base `next`, following the implementation requirements above. - Clear the background's `connectedSites` entries for a removed address on the address-level and wallet-level removal paths, next to the existing `dropSitePermissions` call; one small shared helper, not two copies. - A unit test drives each removal with a live connected site and asserts the entry is gone; it must fail against current `next`. - The PR body states, from the code, what `connectedSites` gates and whether it survives a service-worker restart. - Kept separate from https://git.eeqj.de/sneak/AutistMask/issues/406 (revoking a session connection), which touches the same map and follows this unit. Model: opus-5-5

clawbot referenced this issue

2026-10-03 14:21:22 +02:00

Review toward 1.0: identify and file all next steps #382

clawbot referenced this issue from a commit

2026-10-04 02:58:53 +02:00

harden: end a site's unremembered connection when its address or wallet is removed (closes #245)

clawbot referenced a pull request that will close this issue

2026-10-04 03:00:56 +02:00

harden: end a site's unremembered connection when its address or wallet is removed #416

clawbot closed this issue

2026-10-04 04:58:38 +02:00

clawbot referenced this issue from a commit