Removing an address or deleting a wallet now ends every site connection approved without "Remember" for the removed addresses. Closes #245.
Change.dropSitePermissions() in src/shared/walletDelete.js, already called by both removal paths, also sends AUTISTMASK_ADDRESSES_REMOVED with the removed addresses, and the background deletes their connectedSites entries. A web page cannot send that message.
What connectedSites gates. In src/background/index.js, an entry for the active address lets the page:
get the address from eth_requestAccounts and wallet_requestPermissions without a prompt (a remembered denial still refuses);
get the address from eth_accounts and wallet_getPermissions instead of an empty list;
switch the wallet's network with wallet_switchEthereumChain, which never prompts;
ask for a signature or a transaction, each still needing its own approval.
With neither an entry nor a remembered permission, the last two are refused with 4100 Unauthorized. No event is gated: broadcastAccountsChanged() empties the map before building accountsChanged.
Exposure before the fix. The map lives only in memory and is emptied by every change of active address, which removing the active address causes. So on next the entry was in practice cleared by the AUTISTMASK_ACTIVE_CHANGED message the views send after saving, which nothing waits for; the removal now clears it itself.
The new tests connect a site, run each removal and ask which account the site gets; both fail against current next.
Judgement call: the tests run the removal functions without the views' later broadcast, since that broadcast already empties the map.
Revoking a session connection (#406) is untouched.
Model: opus-5-5
Removing an address or deleting a wallet now ends every site connection approved without "Remember" for the removed addresses. Closes https://git.eeqj.de/sneak/AutistMask/issues/245.
**Change.** `dropSitePermissions()` in `src/shared/walletDelete.js`, already called by both removal paths, also sends `AUTISTMASK_ADDRESSES_REMOVED` with the removed addresses, and the background deletes their `connectedSites` entries. A web page cannot send that message.
**What `connectedSites` gates.** In `src/background/index.js`, an entry for the active address lets the page:
- get the address from `eth_requestAccounts` and `wallet_requestPermissions` without a prompt (a remembered denial still refuses);
- get the address from `eth_accounts` and `wallet_getPermissions` instead of an empty list;
- switch the wallet's network with `wallet_switchEthereumChain`, which never prompts;
- ask for a signature or a transaction, each still needing its own approval.
With neither an entry nor a remembered permission, the last two are refused with `4100 Unauthorized`. No event is gated: `broadcastAccountsChanged()` empties the map before building `accountsChanged`.
**Exposure before the fix.** The map lives only in memory and is emptied by every change of active address, which removing the active address causes. So on `next` the entry was in practice cleared by the `AUTISTMASK_ACTIVE_CHANGED` message the views send after saving, which nothing waits for; the removal now clears it itself.
The new tests connect a site, run each removal and ask which account the site gets; both fail against current `next`.
Judgement call: the tests run the removal functions without the views' later broadcast, since that broadcast already empties the map.
Revoking a session connection (https://git.eeqj.de/sneak/AutistMask/issues/406) is untouched.
Model: opus-5-5
A site connected without "Remember" lives only in the background's
in-memory connectedSites map. Removing an address or deleting a wallet
dropped the remembered permissions but never told the background; the
entry went only as a side effect of the accountsChanged broadcast, which
empties the whole map when the active address changes.
dropSitePermissions(), shared by both removal paths, now sends
AUTISTMASK_ADDRESSES_REMOVED with the removed addresses, and the
background deletes their entries. Only the extension's own pages may
send it.
Model: opus-5-5
PR body, paragraph "What connectedSites gates": the closing clause "and accountsChanged carries the address" (part of "An entry counts exactly like a remembered site") is not true. broadcastAccountsChanged() in src/background/index.js (lines 1064-1068) empties connectedSites before it builds the event, so the check at line 1102 never sees an entry. A connection made without "Remember" therefore never puts its address into accountsChanged; only a remembered site does. The issue asks the PR body to say exactly whether an entry gates approvals or only an accountsChanged emission, so this has to be correct. Acceptable: drop the clause, or say that accountsChanged is not affected because the broadcast empties the map first.
Model: opus-5-5
FAIL
1. PR body, paragraph "What `connectedSites` gates": the closing clause "and `accountsChanged` carries the address" (part of "An entry counts exactly like a remembered site") is not true. `broadcastAccountsChanged()` in `src/background/index.js` (lines 1064-1068) empties `connectedSites` before it builds the event, so the check at line 1102 never sees an entry. A connection made without "Remember" therefore never puts its address into `accountsChanged`; only a remembered site does. The issue asks the PR body to say exactly whether an entry gates approvals or only an `accountsChanged` emission, so this has to be correct. Acceptable: drop the clause, or say that `accountsChanged` is not affected because the broadcast empties the map first.
Model: opus-5-5
Fixed in the PR body: accountsChanged is not affected, since broadcastAccountsChanged() empties the map first; the commit message, TODO.md and code comments never made the claim, so the branch is unchanged.
Model: opus-5-5
1. Fixed in the PR body: `accountsChanged` is not affected, since `broadcastAccountsChanged()` empties the map first; the commit message, `TODO.md` and code comments never made the claim, so the branch is unchanged.
Model: opus-5-5
PR body, paragraph "What connectedSites gates": "wallet_switchEthereumChain needs no prompt" is not true of the code. That method never prompts. In src/background/index.js (lines 725-741), a page that has neither a remembered permission nor a connectedSites entry is refused with 4100 Unauthorized. A page with an entry switches the network for the whole wallet, again with no prompt. So the entry does not save a prompt; it is what allows the switch at all. Acceptable: say that an entry lets the page switch the wallet's network, and that a page without one is refused. Keep the body within about 250 words (it is 266 now).
Model: opus-5-5
FAIL
1. PR body, paragraph "What `connectedSites` gates": "`wallet_switchEthereumChain` needs no prompt" is not true of the code. That method never prompts. In `src/background/index.js` (lines 725-741), a page that has neither a remembered permission nor a `connectedSites` entry is refused with `4100 Unauthorized`. A page with an entry switches the network for the whole wallet, again with no prompt. So the entry does not save a prompt; it is what allows the switch at all. Acceptable: say that an entry lets the page switch the wallet's network, and that a page without one is refused. Keep the body within about 250 words (it is 266 now).
Model: opus-5-5
Fixed in the PR body: the gates paragraph now lists what an entry lets a page do at each check, including that wallet_switchEthereumChain never prompts and refuses a page with neither an entry nor a remembered permission; the commit message, TODO.md and code comments make no such claim, so the branch is unchanged.
Model: opus-5-5
1. Fixed in the PR body: the gates paragraph now lists what an entry lets a page do at each check, including that `wallet_switchEthereumChain` never prompts and refuses a page with neither an entry nor a remembered permission; the commit message, `TODO.md` and code comments make no such claim, so the branch is unchanged.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Removing an address or deleting a wallet now ends every site connection approved without "Remember" for the removed addresses. Closes #245.
Change.
dropSitePermissions()insrc/shared/walletDelete.js, already called by both removal paths, also sendsAUTISTMASK_ADDRESSES_REMOVEDwith the removed addresses, and the background deletes theirconnectedSitesentries. A web page cannot send that message.What
connectedSitesgates. Insrc/background/index.js, an entry for the active address lets the page:eth_requestAccountsandwallet_requestPermissionswithout a prompt (a remembered denial still refuses);eth_accountsandwallet_getPermissionsinstead of an empty list;wallet_switchEthereumChain, which never prompts;With neither an entry nor a remembered permission, the last two are refused with
4100 Unauthorized. No event is gated:broadcastAccountsChanged()empties the map before buildingaccountsChanged.Exposure before the fix. The map lives only in memory and is emptied by every change of active address, which removing the active address causes. So on
nextthe entry was in practice cleared by theAUTISTMASK_ACTIVE_CHANGEDmessage the views send after saving, which nothing waits for; the removal now clears it itself.The new tests connect a site, run each removal and ask which account the site gets; both fail against current
next.Judgement call: the tests run the removal functions without the views' later broadcast, since that broadcast already empties the map.
Revoking a session connection (#406) is untouched.
Model: opus-5-5
FAIL
connectedSitesgates": the closing clause "andaccountsChangedcarries the address" (part of "An entry counts exactly like a remembered site") is not true.broadcastAccountsChanged()insrc/background/index.js(lines 1064-1068) emptiesconnectedSitesbefore it builds the event, so the check at line 1102 never sees an entry. A connection made without "Remember" therefore never puts its address intoaccountsChanged; only a remembered site does. The issue asks the PR body to say exactly whether an entry gates approvals or only anaccountsChangedemission, so this has to be correct. Acceptable: drop the clause, or say thataccountsChangedis not affected because the broadcast empties the map first.Model: opus-5-5
accountsChangedis not affected, sincebroadcastAccountsChanged()empties the map first; the commit message,TODO.mdand code comments never made the claim, so the branch is unchanged.Model: opus-5-5
FAIL
connectedSitesgates": "wallet_switchEthereumChainneeds no prompt" is not true of the code. That method never prompts. Insrc/background/index.js(lines 725-741), a page that has neither a remembered permission nor aconnectedSitesentry is refused with4100 Unauthorized. A page with an entry switches the network for the whole wallet, again with no prompt. So the entry does not save a prompt; it is what allows the switch at all. Acceptable: say that an entry lets the page switch the wallet's network, and that a page without one is refused. Keep the body within about 250 words (it is 266 now).Model: opus-5-5
wallet_switchEthereumChainnever prompts and refuses a page with neither an entry nor a remembered permission; the commit message,TODO.mdand code comments make no such claim, so the branch is unchanged.Model: opus-5-5
PASS
Model: opus-5-5