[P2][Trust] Verification Mode should disclose or capture non-fetch network resource loads

[baixiangcpp]

Summary

In-app Verification Mode currently observes window.fetch and navigator.sendBeacon, but it does not observe every browser network path that matters for Byteflow's external-request and media-preview tools.

This can make the verification panel undercount network activity. For example, an external media preview rendered through <img src="...">, a direct anchor download/navigation, an XHR request, or other resource load would not necessarily be captured by the current monkey-patches.

Why this matters

Verification Mode is framed as a way to help users verify local processing and external-request boundaries. If it misses browser resource loads, users may interpret "0 external hosts observed" as stronger evidence than the feature can actually provide.

This is especially relevant for tools that use public image/video thumbnail URLs or browser-native resource loading rather than only fetch().

Current behavior

Relevant code:

• src/components/layout/verification-mode-panel.tsx
  • wraps window.fetch;
  • wraps navigator.sendBeacon;
  • wraps Storage.prototype.setItem/removeItem/clear;
  • records only sanitized origin, method, path type, and timestamp.
• src/core/trust/verification-mode.ts
  • sanitizeVerificationUrl() intentionally strips path/query and keeps origin only.

This is good from a privacy perspective, but the network capture scope is incomplete.

Expected behavior

Choose one of these implementation paths.

Option A: make capture broader

Add browser-safe observation for resource loads without recording paths/query strings/payloads:

• use PerformanceObserver for resource entries where available;
• also inspect performance.getEntriesByType("resource") when enabling the panel so already-loaded resources can be reported;
• record sanitized origin, resource initiator type, same-origin/external classification, and timestamp only;
• keep payload/body/query/header values out of the panel.

Resource initiator types worth distinguishing:

fetch
xmlhttprequest
img
script
link
css
beacon
other

Option B: make scope explicit

If broad resource observation is too noisy or browser-dependent, clearly label the panel as fetch/beacon/storage verification only:

• UI copy should say it does not capture every browser resource load;
• Trust Center copy should explain when DevTools Network is still required;
• tests should lock the disclaimer.

Suggested implementation plan

1. Add a captureScope or observedBy field to VerificationNetworkEntry.
2. Add PerformanceObserver support behind a feature check.
3. Deduplicate observed entries by origin + initiator type + coarse time bucket so the panel stays readable.
4. Preserve the existing privacy rule: never record full URL, query string, request body, response body, headers, or filenames.
5. Update UI copy and Trust Center copy to explain the scope.
6. Add tests for:
   • fetch is observed;
   • sendBeacon is observed;
   • synthetic resource entries are sanitized if PerformanceObserver logic is factored into a pure helper;
   • paths/query strings never appear;
   • the UI includes the scope disclaimer if Option B is chosen.

Acceptance criteria

• Verification Mode no longer implies complete network coverage if it only captures fetch/beacon.
• Either resource-load observation is added, or the UI/Trust Center clearly documents the narrower scope.
• External origins remain sanitized to origin only.
• No path, query string, header, body, payload, filename, or response content is recorded.
• Tests cover the chosen behavior and prevent over-claiming.
• 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/components/layout/verification-mode-panel.tsx
• src/core/trust/verification-mode.ts
• src/app/[lang]/trust-center/page.tsx
• media/external-request tools that display external resources