sneak, on #211 (comment): "we don’t want to send user data to anything but the rpc endpoint, why are we contacting blockscout or etherscan? this is a major privacy leak bug and use of these must default to off and be opt-in in prefs or during onboarding or both."
Severity: major (his word).
What happens
Out of the box the wallet sends user data to services other than the configured RPC endpoint: the configured Blockscout API (user addresses, for history and token lookups) and Etherscan (the address being confirmed, for its label), as README.md External Services describes.
What should happen
By default the wallet contacts nothing but the configured RPC endpoint with any user data. Blockscout and Etherscan lookups are off by default and turned on only by the user, in the preferences, during onboarding, or both. Whatever stops working while they are off says so plainly on the screen instead of failing silently.
Definition of done
A fresh install, with no preference changed, sends no request carrying user data to Blockscout or Etherscan; checked in a headless browser in a container against a test network, by watching every request the extension makes.
Each lookup has its own opt-in preference, off by default, and onboarding offers them; turning one on makes its feature work as before.
Screens that rely on a lookup that is off say so, in plain words.
README.md External Services and Privacy say what is contacted by default (only the RPC endpoint) and what each opt-in adds.
One reviewed PR on next, or a small series.
The RULES.md wording question on #211 follows from this: its first item now becomes "only the configured RPC endpoint, unless the user opts in". Price data is being moved to the chain under #525.
Model: opus-5-5
sneak, on https://git.eeqj.de/sneak/AutistMask/issues/211#issuecomment-153444: "we don’t want to send user data to anything but the rpc endpoint, why are we contacting blockscout or etherscan? this is a major privacy leak bug and use of these must default to off and be opt-in in prefs or during onboarding or both."
Severity: major (his word).
## What happens
Out of the box the wallet sends user data to services other than the configured RPC endpoint: the configured Blockscout API (user addresses, for history and token lookups) and Etherscan (the address being confirmed, for its label), as `README.md` External Services describes.
## What should happen
By default the wallet contacts nothing but the configured RPC endpoint with any user data. Blockscout and Etherscan lookups are off by default and turned on only by the user, in the preferences, during onboarding, or both. Whatever stops working while they are off says so plainly on the screen instead of failing silently.
## Definition of done
- [ ] A fresh install, with no preference changed, sends no request carrying user data to Blockscout or Etherscan; checked in a headless browser in a container against a test network, by watching every request the extension makes.
- [ ] Each lookup has its own opt-in preference, off by default, and onboarding offers them; turning one on makes its feature work as before.
- [ ] Screens that rely on a lookup that is off say so, in plain words.
- [ ] `README.md` External Services and Privacy say what is contacted by default (only the RPC endpoint) and what each opt-in adds.
- [ ] One reviewed PR on `next`, or a small series.
The `RULES.md` wording question on https://git.eeqj.de/sneak/AutistMask/issues/211 follows from this: its first item now becomes "only the configured RPC endpoint, unless the user opts in". Price data is being moved to the chain under https://git.eeqj.de/sneak/AutistMask/issues/525.
Model: opus-5-5
clawbot
self-assigned this 2026-10-21 12:09:20 +02:00
Plan: two PRs to next, in this order, so next never shows less than it does now.
#669: tracked tokens' balances read through the RPC endpoint, so they do not depend on Blockscout.
This issue, one PR:
Two preferences in the stored profile (DEFAULT_STATE and normalizePersisted() in src/shared/persistedState.js), both off: Blockscout lookups, and Etherscan label checks. One setting each for every network.
Each request is skipped where it is made when its preference is off: fetchTokenBalances() in src/shared/balances.js, the history requests in src/shared/transactions.js, loadFullTxDetails() in src/popup/views/transactionDetail.js, checkEtherscanLabel() in src/shared/etherscanLabels.js. Settings' own test of a Blockscout URL, which the user presses and which carries no user data, stays.
Settings: two checkboxes, unticked, each with one plain sentence on what it sends and to whom. Onboarding (src/popup/views/welcome.js / addWallet.js) offers the same two, unticked.
While Blockscout is off, the screens say what is missing in a plain line where the data would be: no transaction history on Home, AddressDetail and AddressToken; only tracked tokens shown; no decoded details on TransactionDetail. While the Etherscan check is off, the confirmation screens say no Etherscan label check was made. Each line names the setting that turns it on.
README External Services and Privacy: by default the wallet contacts only the RPC endpoint with user data; what each opt-in adds. Links the user clicks to open a page are not requests the wallet makes.
Browser check in a container, headless, on a test network: a fresh install with no preference changed makes no request to Blockscout or Etherscan, every request watched; with each turned on, its feature works as on next.
Model: opus-5-5
Plan: two PRs to `next`, in this order, so `next` never shows less than it does now.
1. https://git.eeqj.de/sneak/AutistMask/issues/669: tracked tokens' balances read through the RPC endpoint, so they do not depend on Blockscout.
2. This issue, one PR:
- Two preferences in the stored profile (`DEFAULT_STATE` and `normalizePersisted()` in `src/shared/persistedState.js`), both off: Blockscout lookups, and Etherscan label checks. One setting each for every network.
- Each request is skipped where it is made when its preference is off: `fetchTokenBalances()` in `src/shared/balances.js`, the history requests in `src/shared/transactions.js`, `loadFullTxDetails()` in `src/popup/views/transactionDetail.js`, `checkEtherscanLabel()` in `src/shared/etherscanLabels.js`. Settings' own test of a Blockscout URL, which the user presses and which carries no user data, stays.
- Settings: two checkboxes, unticked, each with one plain sentence on what it sends and to whom. Onboarding (`src/popup/views/welcome.js` / `addWallet.js`) offers the same two, unticked.
- While Blockscout is off, the screens say what is missing in a plain line where the data would be: no transaction history on Home, AddressDetail and AddressToken; only tracked tokens shown; no decoded details on TransactionDetail. While the Etherscan check is off, the confirmation screens say no Etherscan label check was made. Each line names the setting that turns it on.
- README External Services and Privacy: by default the wallet contacts only the RPC endpoint with user data; what each opt-in adds. Links the user clicks to open a page are not requests the wallet makes.
- Browser check in a container, headless, on a test network: a fresh install with no preference changed makes no request to Blockscout or Etherscan, every request watched; with each turned on, its feature works as on `next`.
Model: opus-5-5
#671 does this. A new install asks Blockscout and Etherscan nothing until the user ticks "Use Blockscout" or "Check recipients on Etherscan", offered unticked on Welcome and in Settings. While either is off, the screens that rely on it say so in a plain line naming the setting. README and the user guide say what is contacted by default and what each setting adds. The Chrome suite now records every request a fresh install makes and turns each setting on in turn.
Model: opus-5-5
https://git.eeqj.de/sneak/AutistMask/pulls/671 does this. A new install asks Blockscout and Etherscan nothing until the user ticks "Use Blockscout" or "Check recipients on Etherscan", offered unticked on Welcome and in Settings. While either is off, the screens that rely on it say so in a plain line naming the setting. README and the user guide say what is contacted by default and what each setting adds. The Chrome suite now records every request a fresh install makes and turns each setting on in turn.
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.
sneak, on #211 (comment): "we don’t want to send user data to anything but the rpc endpoint, why are we contacting blockscout or etherscan? this is a major privacy leak bug and use of these must default to off and be opt-in in prefs or during onboarding or both."
Severity: major (his word).
What happens
Out of the box the wallet sends user data to services other than the configured RPC endpoint: the configured Blockscout API (user addresses, for history and token lookups) and Etherscan (the address being confirmed, for its label), as
README.mdExternal Services describes.What should happen
By default the wallet contacts nothing but the configured RPC endpoint with any user data. Blockscout and Etherscan lookups are off by default and turned on only by the user, in the preferences, during onboarding, or both. Whatever stops working while they are off says so plainly on the screen instead of failing silently.
Definition of done
README.mdExternal Services and Privacy say what is contacted by default (only the RPC endpoint) and what each opt-in adds.next, or a small series.The
RULES.mdwording question on #211 follows from this: its first item now becomes "only the configured RPC endpoint, unless the user opts in". Price data is being moved to the chain under #525.Model: opus-5-5
Plan: two PRs to
next, in this order, sonextnever shows less than it does now.DEFAULT_STATEandnormalizePersisted()insrc/shared/persistedState.js), both off: Blockscout lookups, and Etherscan label checks. One setting each for every network.fetchTokenBalances()insrc/shared/balances.js, the history requests insrc/shared/transactions.js,loadFullTxDetails()insrc/popup/views/transactionDetail.js,checkEtherscanLabel()insrc/shared/etherscanLabels.js. Settings' own test of a Blockscout URL, which the user presses and which carries no user data, stays.src/popup/views/welcome.js/addWallet.js) offers the same two, unticked.next.Model: opus-5-5
#671 does this. A new install asks Blockscout and Etherscan nothing until the user ticks "Use Blockscout" or "Check recipients on Etherscan", offered unticked on Welcome and in Settings. While either is off, the screens that rely on it say so in a plain line naming the setting. README and the user guide say what is contacted by default and what each setting adds. The Chrome suite now records every request a fresh install makes and turns each setting on in turn.
Model: opus-5-5