1 Commits
Author SHA1 Message Date
sneak bd2b5ce96a fix: Blockscout and Etherscan lookups are off until the user turns them on (closes #668)
check / check (push) Waiting to run
e2e / e2e-chrome (push) Waiting to run
e2e / e2e-firefox (push) Waiting to run
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
2026-10-21 14:29:38 +00:00
5 changed files with 101 additions and 58 deletions
+30 -22
View File
@@ -18,13 +18,14 @@ don't implement any crypto, and don't send user-specific data anywhere but a
unless the user turns on one of the two lookups below. Out of the box the
extension contacts the configured RPC node for blockchain interactions and a
public CoinDesk API (no API key) for realtime price information, which is sent
token symbols and nothing else. Two more services are asked nothing until the
user turns them on, on the Welcome screen or in Settings: a Blockscout
block-explorer API for transaction history, the tokens the user has not tracked
and transaction details ("Use Blockscout"), and best-effort Etherscan address
label lookups during transaction confirmation ("Check recipients on Etherscan").
A community-maintained phishing domain blocklist is built into the extension at
build time and checked locally; nothing is fetched for it at runtime.
token symbols and nothing else. Two more services are sent none of the user's
data until the user turns them on, on the Welcome screen or in Settings: a
Blockscout block-explorer API for transaction history, the tokens the user has
not tracked and transaction details ("Use Blockscout"), and best-effort
Etherscan address label lookups during transaction confirmation ("Check
recipients on Etherscan"). A community-maintained phishing domain blocklist is
built into the extension at build time and checked locally; nothing is fetched
for it at runtime.
In the extension is a hardcoded list of the top ERC20 contract addresses. You
can add any ERC20 contract by contract address if you wish, but the hardcoded
@@ -428,16 +429,20 @@ mainnet must take it down, both while Settings is still on screen.
It also covers what a new install sends to Blockscout and Etherscan
([#668](https://git.eeqj.de/sneak/AutistMask/issues/668)). The route handler
records every request the extension makes, from its pages and its background
worker, from the moment the browser starts. Welcome must offer "Use Blockscout"
and "Check recipients on Etherscan" unticked. With neither changed, Home,
AddressDetail, AddressToken and ConfirmTx must show the lines saying what is
off; the popup is then closed until the background has run a balance refresh of
its own, and not one recorded request may have gone to Blockscout or Etherscan.
Each is then ticked in Settings, after which Blockscout must be asked for the
history and the token balances, and ConfirmTx must ask Etherscan about the
recipient and show the label the stub page gives it. Both stay on for the rest
of the run. TransactionDetail with "Use Blockscout" off is not driven here,
since no history row leads to it then; the unit tests cover it.
worker, from when the harness installs it, before the first popup page opens; a
request the background worker makes while it starts up, before then, is not
recorded. Welcome must offer "Use Blockscout" and "Check recipients on
Etherscan" unticked. With neither changed, Home, AddressDetail, AddressToken and
ConfirmTx must show the lines saying what is off; the popup is then closed until
the background has run a balance refresh of its own, and not one recorded
request may have gone to Blockscout or Etherscan. "Use Blockscout" is then
ticked from AddressDetail's gear: on "Back", AddressDetail must ask Blockscout
for its history and no longer say it is off, and Blockscout must then be asked
for the token balances. "Check recipients on Etherscan" is ticked from
ConfirmTx's gear: on "Back", ConfirmTx must ask Etherscan about the recipient
and show the label the stub page gives it. Both stay on for the rest of the run.
TransactionDetail with "Use Blockscout" off is not driven here, since no history
row leads to it then; the unit tests cover it.
It also covers the confirmation screen, for both a native ETH send and an ERC-20
send: Send disabled while the fee estimate is in flight, enabled once it lands,
@@ -1599,7 +1604,10 @@ renders as it goes, and `viewRouter.js` records every screen that reaches
more — rendering it a second time would re-fetch and overwrite what it holds,
such as an edit typed into Settings and not yet saved. Home is the one screen
"Back" always re-renders, so the wallet list reflects anything that changed
while the user was away from it.
while the user was away from it. Changing "Use Blockscout" or "Check recipients
on Etherscan" in Settings makes every screen but Settings count as not yet
rendered, so "Back" renders the screen it lands on under the new setting; the
stack is left as it is.
A network switch leaves every screen on the page showing the previous network.
The user makes it in Settings, or approves a site's request and the background
@@ -2732,10 +2740,10 @@ view would leave a wallet one click from deletion.
AutistMask is not a fully self-contained offline tool. By default it sends the
user's data to one service only, the Ethereum RPC endpoint, and asks one more,
the CoinDesk price API, for prices with nothing but token symbols. Two more
services are asked nothing until the user turns on the setting for each, on the
Welcome screen or in Settings: Blockscout ("Use Blockscout") and Etherscan
("Check recipients on Etherscan"). Both settings are off in a new profile, and
each is one setting for every network.
services are sent none of the user's data until the user turns on the setting
for each, on the Welcome screen or in Settings: Blockscout ("Use Blockscout")
and Etherscan ("Check recipients on Etherscan"). Both settings are off in a new
profile, and each is one setting for every network.
Contacted by default:
+3 -3
View File
@@ -72,9 +72,9 @@ analytics, use a portfolio tracker. The wallet is not the place for any of that.
AutistMask is a browser extension that runs entirely in your browser. It does
not have a backend server. Out of the box it sends your data only to the
Ethereum RPC endpoint, and asks the CoinDesk price API for prices with nothing
but token symbols. Blockscout and Etherscan are asked nothing until you turn on
"Use Blockscout" or "Check recipients on Etherscan", on the Welcome screen or
later in Settings. Both are off in a new install.
but token symbols. Blockscout and Etherscan are sent none of your data until you
turn on "Use Blockscout" or "Check recipients on Etherscan", on the Welcome
screen or later in Settings. Both are off in a new install.
### External Services
+5 -3
View File
@@ -40,9 +40,11 @@ function markViewRendered(view) {
// Begin a fresh page-load scope. The popup gets one by being loaded, and
// asks for one after a network switch, because every screen then on the page
// shows the previous network (showNewNetwork() in views/settings.js); the
// unit tests, which simulate several page loads against one module
// instance, ask for one too.
// shows the previous network (showNewNetwork() in views/settings.js), and
// after "Use Blockscout" or "Check recipients on Etherscan" changes in
// Settings, because every screen then on the page was drawn under the old
// setting; the unit tests, which simulate several page loads against one
// module instance, ask for one too.
function resetRenderedViews() {
renderedViews.clear();
}
+9 -2
View File
@@ -367,11 +367,16 @@ function init(_ctx) {
showFlash("Saved.");
});
// Welcome offers the same two settings, and Back from here to Welcome only
// unhides it, so its boxes are set here too.
// The screens under Settings were drawn under the old setting, so each
// change makes every screen but Settings count as not yet drawn, as a
// network switch does, and Back draws the one it lands on again. Welcome
// offers the same two settings and is only unhidden on Back, so its boxes
// are set here too.
$("settings-use-blockscout").addEventListener("change", async () => {
state.useBlockscout = $("settings-use-blockscout").checked;
$("welcome-use-blockscout").checked = state.useBlockscout;
resetRenderedViews();
markViewRendered("settings");
await saveState();
});
@@ -383,6 +388,8 @@ function init(_ctx) {
).checked;
$("welcome-check-recipients-on-etherscan").checked =
state.checkRecipientsOnEtherscan;
resetRenderedViews();
markViewRendered("settings");
await saveState();
},
);
+54 -28
View File
@@ -274,10 +274,13 @@ test("the exact confirmation phrase erases the record and reloads into Welcome (
// 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, from the moment the browser
// starts, in env.routeOpts.requests. 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.
// 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.
// 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
@@ -444,23 +447,41 @@ test("with neither setting changed, nothing has reached Blockscout or Etherscan,
await visible(env.page, "#view-address");
});
test("turning on Use Blockscout in Settings asks Blockscout for the history and the tokens (#668)", async (env) => {
// Ticked from AddressDetail's gear, so Back lands on the screen that said the
// setting is off.
test("turning on Use Blockscout from AddressDetail's gear asks Blockscout for that screen's history on Back, then for the tokens (#668)", async (env) => {
await openAddressDetail(env.page);
await waitForHistoryOff(env.page, "tx-list");
await openSettings(env.page);
await env.page.check("#settings-use-blockscout");
await waitForPersisted(env.page, "useBlockscout", true, "once ticked");
const asked = Promise.all([
env.page.waitForRequest(
(r) =>
r.url().includes("blockscout.com") &&
r.url().endsWith("/transactions"),
),
env.page.waitForRequest((r) => r.url().endsWith("/token-balances"), {
timeout: 30000,
}),
]);
const historyAsked = env.page.waitForRequest(
(r) =>
r.url().includes("blockscout.com") &&
r.url().endsWith("/transactions"),
);
const tokensAsked = env.page.waitForRequest(
(r) => r.url().endsWith("/token-balances"),
{ timeout: 30000 },
);
await env.page.click("#btn-settings-back");
await visible(env.page, "#view-address");
await historyAsked;
await env.page.waitForFunction(
() =>
document
.getElementById("tx-list")
.textContent.includes("No transactions found."),
null,
{ timeout: 15000 },
);
assert(
!(await env.page.isVisible("#address-tokens-note")),
"AddressDetail still says only tracked tokens are listed",
);
await goHome(env.page);
await asked;
await tokensAsked;
await env.page.waitForFunction(
() =>
document
@@ -475,11 +496,21 @@ test("turning on Use Blockscout in Settings asks Blockscout for the history and
);
});
// Left on for the rest of the run, as the check was always made before #668.
test("turning on Check recipients on Etherscan in Settings has ConfirmTx ask Etherscan and show its label (#668)", async (env) => {
// Ticked from ConfirmTx's gear, so Back lands on the screen that said no
// Etherscan check was made. Left on for the rest of the run, as the check was
// always made before #668.
test("turning on Check recipients on Etherscan from ConfirmTx's gear has ConfirmTx ask Etherscan on Back and show its label (#668)", async (env) => {
env.routeOpts.ethBalanceWei = toHexWei(FUNDED_ETH_WEI);
env.routeOpts.etherscanLabel = "Fake_Phishing668";
try {
await settleOnMain(env, { ethWei: FUNDED_ETH_WEI });
await goToConfirm(env.page, {
token: "ETH",
balance: FUNDED_ETH_TEXT + " ETH",
amount: COMFORTABLE_AMOUNT,
});
await visible(env.page, "#confirm-etherscan-note");
await openSettings(env.page);
await env.page.check("#settings-check-recipients-on-etherscan");
await waitForPersisted(
@@ -488,15 +519,9 @@ test("turning on Check recipients on Etherscan in Settings has ConfirmTx ask Eth
true,
"once ticked",
);
await env.page.click("#btn-settings-back");
await settleOnMain(env, { ethWei: FUNDED_ETH_WEI });
const before = env.routeOpts.requests.length;
await goToConfirm(env.page, {
token: "ETH",
balance: FUNDED_ETH_TEXT + " ETH",
amount: COMFORTABLE_AMOUNT,
});
await env.page.click("#btn-settings-back");
await visible(env.page, "#view-confirm-tx");
await visible(env.page, "#confirm-etherscan-warning", 30000);
assert(
!(await env.page.isVisible("#confirm-etherscan-note")),
@@ -5488,8 +5513,9 @@ async function main() {
// order. The dApp transaction round trip asserts against these bytes
// rather than against anything the extension reported about them.
broadcastTransactions: [],
// Every request the extension makes, from the browser's start, in
// order (#668).
// Every request the extension makes, in order, from when launch()
// installs the route handler, before the first popup page opens
// (#668).
requests: [],
};