Replace unsigned signed_metadata with metadata + SHA-256 asset binding

[Copilot]

createSignedMetadata produced plain JSON with no cryptographic operations, yet named the FormData field signed_metadata — a false integrity signal to API consumers and blockchain indexers.

Changes

• Renamed createSignedMetadata → createMetadata and FormData field signed_metadata → metadata to eliminate the misleading "signed" label
• Added computeSha256(blob) using crypto.subtle.digest('SHA-256', ...) (Web Crypto API, no new dependencies)
• Bound image to metadata by including asset_sha256 in the metadata JSON, enabling the server to verify image↔metadata correspondence

{
  "asset_sha256": "e3b0c44298fc1c149afb....",
  "created_at": 1741827758707,
  "recorder": "ProofSnap Browser Extension",
  "spec_version": "2.0.0",
  "web_source_title": "Example Domain",
  "web_source_url": "https://example.com"
}

The blob is already materialized in prepareUploadFormData (for asset_file), so the hash computation reuses it with no extra I/O.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Security][High] Unsigned provenance metadata allows trivial forgery of blockchain records</issue_title>
<issue_description>## Summary

The createSignedMetadata method in UploadService.ts generates plain JSON metadata and labels it "signed_metadata," but performs zero cryptographic signing. For a provenance/blockchain extension whose core value proposition is tamper-proof capture records, this is a significant integrity gap.

Details

File: src/services/UploadService.ts, lines 449-471

The method constructs a metadata object containing GPS coordinates, creation timestamp, source URL, and device information, then serializes it to JSON and attaches it to the upload FormData as the signed_metadata field. No HMAC, digital signature, or hash binding to the image blob is applied.

Impact:

• Any compromised client or man-in-the-middle (pre-TLS termination) can spoof GPS coordinates, timestamps, and source URLs
• The field name signed_metadata gives a false sense of cryptographic integrity to downstream consumers (API, blockchain indexers, verifiers)
• The image blob itself has no client-side integrity binding (no hash included in metadata)

Suggested Fix

1. If the server handles signing, rename the method and field from createSignedMetadata/signed_metadata to createMetadata/metadata to avoid a false sense of security
2. Ideally, compute a SHA-256 hash of the image blob before upload and include it in the metadata, then HMAC-sign the metadata using a key derived from the user's auth session
3. At minimum, bind the asset hash to the metadata so the server can verify image-metadata correspondence

Differentiation from Existing Issues

Not covered by #10 (XSS/token storage), #11 (token refresh), #20 (verbose logging), or #21 (JSON.parse safety). This concerns the absence of actual cryptographic integrity protection on provenance metadata — the extension's core security claim.

---

Generated by Health Monitor with Omni</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Security][High] Unsigned provenance metadata allows trivial forgery of blockchain records #35

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.