fix: Blockscout and Etherscan lookups are off until the user turns them on (closes #668)

Out of the box the wallet sent the user's addresses to Blockscout for history
and token lookups, and each recipient to Etherscan for its label. Two settings,
"Use Blockscout" and "Check recipients on Etherscan", now gate those requests
where they are made. Both are off in a new profile and offered unticked on
Welcome and in Settings. While one is off, the screens that relied on it say so
in a plain line naming the setting; after either changes in Settings, Back
draws the screen it lands on again. README and the user guide say what is
contacted by default and what each setting adds.

Model: opus-5-5

README.md

@@ -1411,13 +1411,13 @@ that token's previous entry, as a failed ETH balance keeps its figure, or takes
 Blockscout's entry from the same refresh when there is none. Every other token
 comes from the Blockscout `token-balances` response (`fetchTokenBalances()`), so
 tokens do appear without the user adding them, and they keep their previous
-figures while Blockscout fails. Blockscout is asked only while the user has "Use
-Blockscout" on. While it is off, as it is until the user turns it on, a tracked
-token's entry has no holder count and no `decimals` of Blockscout's, so its
-balance is stated at the scale the bundled list or the tracked token records,
-and no other token is listed, those from earlier refreshes included. A tracked
-token is shown when its balance is nonzero, and any other ERC-20 when its
-balance is nonzero and it is in the bundled known-token list or has 1,000 or
+figures while Blockscout fails. The refresh asks Blockscout only while the user
+has "Use Blockscout" on. While it is off, as it is until the user turns it on, a
+tracked token's entry has no holder count and no `decimals` of Blockscout's, so
+its balance is stated at the scale the bundled list or the tracked token
+records, and no other token is listed, those from earlier refreshes included. A
+tracked token is shown when its balance is nonzero, and any other ERC-20 when
+its balance is nonzero and it is in the bundled known-token list or has 1,000 or
 more holders. A token claiming a symbol from the bundled list from any other
 contract address is always dropped, tracked or not, and so is any token claiming
 a symbol that belongs to the native asset and therefore has no legitimate
@@ -2766,7 +2766,7 @@ Contacted by default:
     - **Data sent**: Token symbol strings only (e.g. "ETH", "USDC"). No
       addresses or user-specific data.
 
-Contacted only while the user has turned the setting on:
+Sent the user's data only while the user has turned the setting on:
 
 - **Blockscout block-explorer API** ("Use Blockscout"): Used to fetch
   transaction history (normal transactions and ERC-20 token transfers) for Home,

docs/README.md

@@ -109,14 +109,14 @@ and calldata of a transaction you open. You can change this in Settings to a
 self-hosted Blockscout instance. While it is off, the screens that would show
 history say so, and only the tokens you track are listed.
 
-When it is contacted: only while "Use Blockscout" is on, on every balance
-refresh, whenever a screen showing transaction history is opened, and when you
-open a transaction.
+When it is contacted: while "Use Blockscout" is on, on every balance refresh,
+whenever a screen showing transaction history is opened, and when you open a
+transaction. The one exception, whether or not the setting is on, is pressing
+"Save" beside the Blockscout URL in Settings, which checks that URL by asking it
+for `/stats` and sends none of your data.
 
 What gets sent: your Ethereum addresses (to look up balances and transactions)
-and the hash of each transaction you open. Pressing "Save" beside the Blockscout
-URL in Settings checks that URL by asking it for `/stats`, which sends none of
-your data, whether or not the setting is on.
+and the hash of each transaction you open.
 
 **CoinDesk CADLI price API** (`data-api.coindesk.com`)
 

tests/blockscoutEtherscanSettings.test.js

@@ -1,9 +1,12 @@
-// Blockscout and Etherscan are asked nothing until the user turns them on
-// (https://git.eeqj.de/sneak/AutistMask/issues/668). A new profile has "Use
-// Blockscout" and "Check recipients on Etherscan" both off. Each request to
-// either service is skipped where it is made while its setting is off, and
-// made while it is on; the popup and the background hand the stored setting
-// to the code that makes the request.
+// Blockscout and Etherscan are sent none of the user's data until the user
+// turns them on (https://git.eeqj.de/sneak/AutistMask/issues/668). A new
+// profile has "Use Blockscout" and "Check recipients on Etherscan" both off.
+// Each request to either service is skipped where it is made while its setting
+// is off, and made while it is on; the popup and the background hand the
+// stored setting to the code that makes the request. The one exception is the
+// endpoint check Settings makes when the user presses "Save" beside the
+// Blockscout URL. It asks only for `/stats` and carries no user data; it is
+// made whether or not the setting is on.
 //
 // The functions that make the requests are driven directly, against a fetch()
 // that records every URL it is asked for. The screens are driven through the

tests/e2e/run.js

@@ -269,18 +269,22 @@ test("the exact confirmation phrase erases the record and reloads into Welcome (
     }
 });
 
-// ------------------ Blockscout and Etherscan are asked nothing (#668)
+// ------------------ Blockscout and Etherscan are sent no user data (#668)
 //
-// A fresh install asks neither Blockscout nor Etherscan anything until the
-// user turns on "Use Blockscout" or "Check recipients on Etherscan". The route
-// handler in tests/e2e/network.js records every request the extension makes,
-// from its pages and its background worker, in env.routeOpts.requests.
-// Recording starts when launch() in tests/e2e/harness.js installs that
-// handler, before the first popup page opens; a request the background worker
-// makes while it starts up, before then, is not recorded. These tests drive
-// every screen that would ask either service, and the background's own
-// balance refresh, before either setting is changed, then turn each on and
-// watch its requests start.
+// A fresh install sends Blockscout and Etherscan none of the user's data until
+// the user turns on "Use Blockscout" or "Check recipients on Etherscan". The
+// endpoint check Settings makes when the user presses "Save" beside the
+// Blockscout URL asks only for `/stats` and carries no user data; it is made
+// whether or not the setting is on. The route handler in tests/e2e/network.js
+// records every request the extension makes, from its pages and its background
+// worker, in env.routeOpts.requests. Recording starts when launch() in
+// tests/e2e/harness.js installs that handler, before the first popup page
+// opens; a request the background worker makes while it starts up, before
+// then, is not recorded. These tests drive Home, AddressDetail, AddressToken
+// and ConfirmTx, and the background's own balance refresh, before either
+// setting is changed, then turn each on and watch its requests start.
+// TransactionDetail, which also asks Blockscout, is left to the unit tests in
+// tests/blockscoutEtherscanSettings.test.js.
 
 // What the three transaction lists say while Use Blockscout is off. Written
 // out here rather than imported, so the assertion does not compare the popup