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. The refresh asks Blockscout only while the user
+figures while Blockscout fails. Blockscout is asked only while the user has "Use
-has "Use Blockscout" on. While it is off, as it is until the user turns it on, a
+Blockscout" on. While it is off, as it is until the user turns it on, a tracked
-tracked token's entry has no holder count and no `decimals` of Blockscout's, so
+token's entry has no holder count and no `decimals` of Blockscout's, so its
-its balance is stated at the scale the bundled list or the tracked token
+balance is stated at the scale the bundled list or the tracked token records,
-records, and no other token is listed, those from earlier refreshes included. A
+and no other token is listed, those from earlier refreshes included. A tracked
-tracked token is shown when its balance is nonzero, and any other ERC-20 when
+token is shown when its balance is nonzero, and any other ERC-20 when its
-its balance is nonzero and it is in the bundled known-token list or has 1,000 or
+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.
 
-Sent the user's data only while the user has turned the setting on:
+Contacted 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: while "Use Blockscout" is on, on every balance refresh,
+When it is contacted: only while "Use Blockscout" is on, on every balance
-whenever a screen showing transaction history is opened, and when you open a
+refresh, whenever a screen showing transaction history is opened, and when you
-transaction. The one exception, whether or not the setting is on, is pressing
+open a transaction.
-"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.
+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.
 
 **CoinDesk CADLI price API** (`data-api.coindesk.com`)
 

tests/blockscoutEtherscanSettings.test.js

@@ -1,12 +1,9 @@
-// Blockscout and Etherscan are sent none of the user's data until the user
+// Blockscout and Etherscan are asked nothing until the user turns them on
-// turns them on (https://git.eeqj.de/sneak/AutistMask/issues/668). A new
+// (https://git.eeqj.de/sneak/AutistMask/issues/668). A new profile has "Use
-// profile has "Use Blockscout" and "Check recipients on Etherscan" both off.
+// Blockscout" and "Check recipients on Etherscan" both off. Each request to
-// Each request to either service is skipped where it is made while its setting
+// either service is skipped where it is made while its setting is off, and
-// is off, and made while it is on; the popup and the background hand the
+// made while it is on; the popup and the background hand the stored setting
-// stored setting to the code that makes the request. The one exception is the
+// to the code that makes the request.
-// 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,22 +269,18 @@ test("the exact confirmation phrase erases the record and reloads into Welcome (
     }
 });
 
-// ------------------ Blockscout and Etherscan are sent no user data (#668)
+// ------------------ Blockscout and Etherscan are asked nothing (#668)
 //
-// A fresh install sends Blockscout and Etherscan none of the user's data until
+// A fresh install asks neither Blockscout nor Etherscan anything until the
-// the user turns on "Use Blockscout" or "Check recipients on Etherscan". The
+// user turns on "Use Blockscout" or "Check recipients on Etherscan". The route
-// endpoint check Settings makes when the user presses "Save" beside the
+// handler in tests/e2e/network.js records every request the extension makes,
-// Blockscout URL asks only for `/stats` and carries no user data; it is made
+// from its pages and its background worker, in env.routeOpts.requests.
-// whether or not the setting is on. The route handler in tests/e2e/network.js
+// Recording starts when launch() in tests/e2e/harness.js installs that
-// records every request the extension makes, from its pages and its background
+// handler, before the first popup page opens; a request the background worker
-// worker, in env.routeOpts.requests. Recording starts when launch() in
+// makes while it starts up, before then, is not recorded. These tests drive
-// tests/e2e/harness.js installs that handler, before the first popup page
+// every screen that would ask either service, and the background's own
-// opens; a request the background worker makes while it starts up, before
+// balance refresh, before either setting is changed, then turn each on and
-// then, is not recorded. These tests drive Home, AddressDetail, AddressToken
+// watch its requests start.
-// 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