RFC: Add phishing protection independent of wallet onboarding

[HDauven]

Goal

Explore phishing protection that can warn users whenever the browser extension is installed, including before a mnemonic has been created or imported and without requiring a dApp to instantiate or connect to the wallet.

This should begin as a design/RFC exercise. Different detection signals have materially different false-positive, privacy, maintenance, and extension-store implications.

Threats in scope

• Domains impersonating official Dusk properties.
• Internationalized-domain, homoglyph, typo, and misleading-subdomain lookalikes.
• Known malicious domains from curated/reputation sources.
• Pages asking for a mnemonic, recovery phrase, passphrase, private key, transfer, or purported airdrop while presenting themselves as Dusk-related.
• Newly created phishing pages not yet present in a blocklist.

Options to evaluate

1. Domain allowlist/blocklist and reputation

Maintain a small official-domain allowlist and one or more curated malicious-domain lists. Lists can be bundled with releases and optionally refreshed as signed/versioned data.

Advantages:

• Deterministic and explainable.
• Low runtime cost.
• High confidence for known domains.

Tradeoffs:

• Requires a reporting, review, appeal, and emergency-update process.
• Coverage lags new phishing domains.
• Remote lookups or list updates introduce availability and privacy considerations.

MetaMask uses a phishing controller backed by periodically updated approved/unapproved origins and a maintained phishing-domain repository:

• @metamask/phishing-controller
• MetaMask/eth-phishing-detect

2. Lookalike-domain detection

Compare the normalized hostname against official Dusk domains using IDNA/punycode normalization, Unicode-confusable checks, edit distance, suspicious subdomain placement, and related hostname signals.

This is more targeted than scanning every page for generic wallet words, but needs careful allowlisting and an explanation of which signal triggered the warning.

3. Local page-content heuristics

Score combinations of signals rather than warning on individual words. Possible signals include:

• Dusk branding or wallet terminology on a non-official domain;
• requests for mnemonic/recovery phrase/private key/passphrase;
• transfer, claim, giveaway, or airdrop calls to action;
• secret-like form fields or clipboard instructions; and
• simultaneous use of several high-risk terms.

Content analysis should remain local by default and should be bounded to avoid continuously traversing large or highly dynamic pages. Keyword-only blocking is likely to create false positives on documentation, news, explorers, support pages, and legitimate dApps.

4. Optional remote reputation service

Query a Dusk-operated or third-party reputation service using the minimum required input, ideally a normalized hostname rather than full URLs or page content.

This can improve freshness but requires clear disclosure, secure transport, retention limits, provider governance, and an opt-out decision. It should degrade safely when offline.

Warning UX to evaluate

• High-confidence known malicious domain: extension-owned interstitial before interaction.
• Medium-confidence heuristic match: non-blocking banner and/or extension badge.
• Clearly state which signals triggered the warning.
• Provide Go back, Continue anyway, Trust/allowlist, and Report mistake/site flows appropriate to the confidence level.
• Do not imply that absence of a warning means a site is safe.
• Ensure page scripts cannot spoof or silently dismiss an extension-owned high-confidence warning.

Existing extension capabilities

The Chrome and Firefox builds already install content scripts on HTTP(S) pages and request broad host access, so protection can technically run before wallet onboarding. It should not depend on vault state, unlocked state, account creation, or dApp permissions.

Privacy and store-review constraints

Scanning page text or URLs counts as handling website content/browsing activity even if processing stays local. The design therefore needs matching store-listing and privacy-policy disclosures.

• Chrome requires browsing/content access to be necessary for a prominently described user-facing feature, with minimum permissions and accurate disclosures.
• Mozilla requires self-contained code, secure data transmission, limited collection, and transparent handling.
• Remotely refreshed JSON/domain lists are data; remotely fetched JavaScript or WASM must not be executed as extension code.
• Full DOM/page content should not be transmitted by default.

References:

• Chrome Web Store program policies
• Chrome user-data guidance
• Mozilla Add-on Policies
• MetaMask deceptive-site warning and privacy behavior

RFC deliverables / acceptance criteria

• Threat model and definition of confidence levels.
• Comparison of the four approaches above, including whether a hybrid is justified.
• Official Dusk domain inventory and lookalike rules.
• Data-source ownership, update cadence, signing/versioning, and appeal process.
• UX prototypes for blocking and non-blocking warnings.
• False-positive and false-negative test corpus.
• Performance budget for startup, navigation, and dynamic-page scanning.
• Privacy/data-flow assessment and required Chrome/Firefox disclosures.
• Behavior before onboarding, while locked, and while unlocked.
• Store-review plan confirming that no remote executable code is introduced.