Found while writing the first test coverage for the address-poisoning filters
(#160 / PR #175), and deliberately not fixed there to keep that PR reviewable.
README.md:810-814 promises:
> All of the above filters (known symbol verification, low-holder threshold,
> fraud contract blocklist, dust threshold) are settings that default to on but
> can be individually disabled by the user. AutistMask is designed as a sharp
> tool — users who understand the risks can configure the wallet to show
> everything unfiltered, unix-style.
Known-symbol verification cannot be disabled. There is:
no state flag for it — src/shared/state.js:24-27 carries flags for the
other three filters only,
no checkbox for it — src/popup/index.html:954-976 renders three,
and no flag consulted before it runs — src/shared/transactions.js:222-229
applies the check unconditionally, before any filter setting is read.
So three of the four documented filters are user-configurable and the fourth is
mandatory. The README states otherwise, in the section that is the wallet's
main security claim.
The decision this needs
Either the code or the README is wrong, and it is worth deciding deliberately
rather than defaulting:
(a) Add the setting. Matches the documented promise and the stated
"sharp tool" philosophy. Costs a state flag, a checkbox, and a code path.
(b) Change the README. Argue that symbol spoofing is categorically
different from the other three — it is not a heuristic with false positives
but a definite mismatch between a claimed symbol and the known contract for
it, so there is no legitimate reason to want it off.
I lean (a), because the README's philosophy paragraph is explicit and unusually
emphatic, and because the other three filters are already individually
disableable — a user who has turned all three off and still sees filtered rows
has no way to understand why. But (b) is defensible and cheaper. State the
choice and reasoning in the PR; if you pick (b), the README edit must be
precise about which filters are configurable.
Implementation requirements (if (a))
Add the state flag alongside the existing three in src/shared/state.js:24-27,
defaulting to on, and make sure it round-trips through the persistence
and migration-defaults path so existing users get the safe default rather
than undefined.
Add the checkbox to the Token Spam Protection group in src/popup/index.html:954-976 and wire it in src/popup/views/settings.js
alongside the others. Match the existing label style and the clickable
affordance policy.
Consult the flag in src/shared/transactions.js:222-229 before applying the
check.
Note the interaction with newFraudContracts: the spoof check currently also
feeds the fraud-contract blocklist. Decide whether disabling display
filtering should also stop populating the blocklist, or only stop hiding
rows. These are different things and the distinction matters — quietly
disabling blocklist learning would be a surprising side effect.
Update the README Settings screen map entry and docs/README.md if they
enumerate the checkboxes.
Test coverage already waiting
PR #175 added tests/transactions.test.js with a test named with a current behaviour: prefix pinning the fact that the filter cannot currently
be turned off. When this is fixed, invert that assertion rather than deleting
it — the test should then prove the filter genuinely bypasses when disabled,
matching how the other three are already covered.
Definition of done
The choice between (a) and (b) is made and justified in the PR.
If (a): the filter can be individually disabled from Settings, defaults
to on, and persists across a popup reopen.
If (a): the newFraudContracts interaction is decided explicitly and
documented.
The current behaviour: test in tests/transactions.test.js is inverted
to assert the correct behaviour.
README (and docs/README.md if applicable) matches the implementation.
TODO.md updated in the same commit.
make check passes.
## Problem
Found while writing the first test coverage for the address-poisoning filters
(#160 / PR #175), and deliberately not fixed there to keep that PR reviewable.
`README.md:810-814` promises:
> All of the above filters (known symbol verification, low-holder threshold,
> fraud contract blocklist, dust threshold) are settings that default to on but
> can be individually disabled by the user. AutistMask is designed as a sharp
> tool — users who understand the risks can configure the wallet to show
> everything unfiltered, unix-style.
Known-symbol verification cannot be disabled. There is:
- no state flag for it — `src/shared/state.js:24-27` carries flags for the
other three filters only,
- no checkbox for it — `src/popup/index.html:954-976` renders three,
- and no flag consulted before it runs — `src/shared/transactions.js:222-229`
applies the check unconditionally, before any filter setting is read.
So three of the four documented filters are user-configurable and the fourth is
mandatory. The README states otherwise, in the section that is the wallet's
main security claim.
## The decision this needs
Either the code or the README is wrong, and it is worth deciding deliberately
rather than defaulting:
- **(a) Add the setting.** Matches the documented promise and the stated
"sharp tool" philosophy. Costs a state flag, a checkbox, and a code path.
- **(b) Change the README.** Argue that symbol spoofing is categorically
different from the other three — it is not a heuristic with false positives
but a definite mismatch between a claimed symbol and the known contract for
it, so there is no legitimate reason to want it off.
I lean (a), because the README's philosophy paragraph is explicit and unusually
emphatic, and because the other three filters are already individually
disableable — a user who has turned all three off and still sees filtered rows
has no way to understand why. But (b) is defensible and cheaper. **State the
choice and reasoning in the PR;** if you pick (b), the README edit must be
precise about which filters are configurable.
## Implementation requirements (if (a))
- Add the state flag alongside the existing three in `src/shared/state.js:24-27`,
defaulting to **on**, and make sure it round-trips through the persistence
and migration-defaults path so existing users get the safe default rather
than `undefined`.
- Add the checkbox to the Token Spam Protection group in
`src/popup/index.html:954-976` and wire it in `src/popup/views/settings.js`
alongside the others. Match the existing label style and the clickable
affordance policy.
- Consult the flag in `src/shared/transactions.js:222-229` before applying the
check.
- Note the interaction with `newFraudContracts`: the spoof check currently also
feeds the fraud-contract blocklist. Decide whether disabling display
filtering should also stop populating the blocklist, or only stop hiding
rows. These are different things and the distinction matters — quietly
disabling blocklist learning would be a surprising side effect.
- Update the README Settings screen map entry and `docs/README.md` if they
enumerate the checkboxes.
## Test coverage already waiting
PR #175 added `tests/transactions.test.js` with a test named with a
`current behaviour:` prefix pinning the fact that the filter cannot currently
be turned off. When this is fixed, invert that assertion rather than deleting
it — the test should then prove the filter genuinely bypasses when disabled,
matching how the other three are already covered.
## Definition of done
- [ ] The choice between (a) and (b) is made and justified in the PR.
- [ ] If (a): the filter can be individually disabled from Settings, defaults
to on, and persists across a popup reopen.
- [ ] If (a): the `newFraudContracts` interaction is decided explicitly and
documented.
- [ ] The `current behaviour:` test in `tests/transactions.test.js` is inverted
to assert the correct behaviour.
- [ ] README (and `docs/README.md` if applicable) matches the implementation.
- [ ] `TODO.md` updated in the same commit.
- [ ] `make check` passes.
clawbot
added this to the 1.0.0 milestone 2026-08-09 07:07:55 +02:00
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.
Problem
Found while writing the first test coverage for the address-poisoning filters
(#160 / PR #175), and deliberately not fixed there to keep that PR reviewable.
README.md:810-814promises:> All of the above filters (known symbol verification, low-holder threshold,
> fraud contract blocklist, dust threshold) are settings that default to on but
> can be individually disabled by the user. AutistMask is designed as a sharp
> tool — users who understand the risks can configure the wallet to show
> everything unfiltered, unix-style.
Known-symbol verification cannot be disabled. There is:
src/shared/state.js:24-27carries flags for theother three filters only,
src/popup/index.html:954-976renders three,src/shared/transactions.js:222-229applies the check unconditionally, before any filter setting is read.
So three of the four documented filters are user-configurable and the fourth is
mandatory. The README states otherwise, in the section that is the wallet's
main security claim.
The decision this needs
Either the code or the README is wrong, and it is worth deciding deliberately
rather than defaulting:
"sharp tool" philosophy. Costs a state flag, a checkbox, and a code path.
different from the other three — it is not a heuristic with false positives
but a definite mismatch between a claimed symbol and the known contract for
it, so there is no legitimate reason to want it off.
I lean (a), because the README's philosophy paragraph is explicit and unusually
emphatic, and because the other three filters are already individually
disableable — a user who has turned all three off and still sees filtered rows
has no way to understand why. But (b) is defensible and cheaper. State the
choice and reasoning in the PR; if you pick (b), the README edit must be
precise about which filters are configurable.
Implementation requirements (if (a))
src/shared/state.js:24-27,defaulting to on, and make sure it round-trips through the persistence
and migration-defaults path so existing users get the safe default rather
than
undefined.src/popup/index.html:954-976and wire it insrc/popup/views/settings.jsalongside the others. Match the existing label style and the clickable
affordance policy.
src/shared/transactions.js:222-229before applying thecheck.
newFraudContracts: the spoof check currently alsofeeds the fraud-contract blocklist. Decide whether disabling display
filtering should also stop populating the blocklist, or only stop hiding
rows. These are different things and the distinction matters — quietly
disabling blocklist learning would be a surprising side effect.
docs/README.mdif theyenumerate the checkboxes.
Test coverage already waiting
PR #175 added
tests/transactions.test.jswith a test named with acurrent behaviour:prefix pinning the fact that the filter cannot currentlybe turned off. When this is fixed, invert that assertion rather than deleting
it — the test should then prove the filter genuinely bypasses when disabled,
matching how the other three are already covered.
Definition of done
to on, and persists across a popup reopen.
newFraudContractsinteraction is decided explicitly anddocumented.
current behaviour:test intests/transactions.test.jsis invertedto assert the correct behaviour.
docs/README.mdif applicable) matches the implementation.TODO.mdupdated in the same commit.make checkpasses.