[P1][Trust] Verification Mode storage allowlist is too broad for future payload-regression detection

[baixiangcpp]

Summary

The in-app Verification Mode currently marks any storage key that starts with byteflow: as allowed. That is too broad for a privacy verification surface.

The site has strong guards against default payload persistence today, but the Verification Mode should help users and maintainers detect future regressions. If a future tool accidentally writes a key like byteflow:jwt-input, byteflow:payload, byteflow:secret, or byteflow:tool-output, the panel would currently mark it as allowed simply because it has the byteflow: prefix.

Why this matters

Verification Mode is a trust feature. Its output needs to be conservative:

• "Allowed" should mean "known safe preference/state key", not merely "owned by Byteflow".
• A broad prefix allowlist can hide exactly the kind of payload-persistence regression the trust surface is supposed to reveal.
• The current storage audit guards are strong, but runtime verification should not assume every future byteflow:* key is harmless.

Current behavior

Relevant code:

• src/core/trust/verification-mode.ts
  • ALLOWED_STORAGE_KEY_PREFIXES = ["byteflow:", "theme"]
  • isAllowedVerificationStorageKey() returns true when the key starts with any allowed prefix.
• src/components/layout/verification-mode-panel.tsx
  • storage writes/removals are rendered as either storageAllowed or storageReview based on that helper.

Because byteflow: is a blanket prefix, nearly every Byteflow-owned key is marked allowed.

Expected behavior

Verification Mode should use a strict known-safe key taxonomy:

• exact safe keys for favorites, recent tools, theme, PWA prompt state, analytics opt-out, and other UI-only preferences;
• narrow prefixes only for generated safe namespaces where the schema is controlled and payload-free;
• denylist or review-first handling for suspicious names even if they start with byteflow:.

Suspicious substrings should force storageReview, for example:

input
output
payload
token
jwt
secret
password
file
blob
image
log
har
request
response
body
content

Suggested implementation plan

1. Replace ALLOWED_STORAGE_KEY_PREFIXES with a structured allowlist:

type VerificationStorageKeyPolicy = {
  exactKeys: string[]
  safePrefixes: string[]
  reviewSubstrings: string[]
}

2. Include known safe keys from existing storage modules:
   • favorite tools key;
   • recent tools key;
   • analytics opt-out key;
   • PWA install prompt state keys;
   • theme preference key;
   • other explicitly reviewed UI preference keys.
3. Treat unknown byteflow:* keys as review-needed by default unless they match a safe exact key or safe namespace.
4. Add a test that a fake key such as byteflow:jwt-input or byteflow:payload is not marked allowed.
5. Add a test that known safe keys remain allowed.
6. Update Trust Center copy if needed to clarify that Verification Mode is conservative and review-first.

Acceptance criteria

• Unknown byteflow:* keys are not automatically marked allowed.
• Keys with suspicious substrings such as payload, input, output, token, jwt, secret, file, log, request, response, or body are marked review-needed.
• Known safe UI preference keys remain marked allowed.
• Verification Mode tests cover safe keys and suspicious keys.
• Guard tests prevent reintroducing broad byteflow: allowlisting.
• npm run test -- tests/component/verification-mode-panel.test.tsx tests/guards/verification-mode-acceptance.test.ts passes.
• npm run check:types and npm run lint pass.

Related code pointers

• src/core/trust/verification-mode.ts
• src/components/layout/verification-mode-panel.tsx
• tests/guards/verification-mode-acceptance.test.ts
• tests/component/verification-mode-panel.test.tsx