Skip to main content

Cross-platform backup fails both directions: Chrome export writes no file, Android export rejected by web restore

Summary

Two independent defects in the backup system. Neither is user error — the export files are valid and restore fine within their own platform. Cross-platform portability, documented as supported, does not work.

Environment

  • Dell Vostro 15 5501 / Windows 11,

  • Chrome 155.0.8059.86 (Official Build, 64-bit)

  • Firefox 143.0 (64-bit) — used for comparison

  • Samsung Galaxy Tab S7 FE 5G, Venice app v1.17.15

  • Web app on Windows 11

Bug 1 — Chrome export silently produces nothing. Windows 11 + Chrome 155.0.8059.86 on a desktop, exporting from a Samsung Galaxy Tab S7 FE 5G backup workflow.

Steps:

  1. Web app → chat drawer → profile → Backup Chat History

  2. Choose zip export, select Downloads as destination

  3. Wait for "backup completed successfully"

Actual: no file appears in C:\Users\<user>\Downloads. No entry in chrome://downloads, so the download manager is never invoked. No blocked-download icon. No exception in console.

Expected: a .zip file lands in the chosen folder.

Notes:

  • Same flow in Firefox 143.0 works — the file downloads normally. Chrome 155 has full File System Access API support; Firefox 143's is partial, so Firefox likely falls back to a blob download while Chrome takes the FS Access path and fails silently. The version gap is consistent with that hypothesis.

  • Console shows a setInterval violation and Clerk preload warnings only.

Bug 2 — Android export cannot be restored in the web app

Steps:

  1. Android app → Settings → Backup & Restore Chats → Backup, with passphrase

  2. Transfer .venicebackup to Windows

  3. Web app → restore → browse for zip → select file → Merge

Actual:

Worker message: Starting restore worker
Worker message: Opening zip
Worker message: error: End of central directory not found

UI: "Backup Restoration Failed — An unexpected error occurred. Please try again."

Expected: restore succeeds. The Android app restores the same file without issue.

Ruled out:

  • Transfer corruption — file sizes verified identical, transfer repeated

  • Picker filter — file selectable via "All Files"

  • Extension — renaming .venicebackup → .zip makes no difference

  • File size — fails identically on a 12.7 MB and a 171 MB export

  • Browser — fails in both Chrome 155 and Firefox 143

Evidence — the two formats

Android .venicebackup is a JSON header followed by raw ciphertext. Header:

{"magic":"venice-backup","formatVersion":2,"frameCount":0,
 "kdf":{"dkLen":32,"N":131072,"p":1,"r":8,"id":"scrypt","saltB64":"..."},
 "cipher":{"id":"xchacha20poly1305"},
 "compression":"gzip",
 "app":{"appVersion":"1.17.15","platform":"android"},
 "createdAt":1791771912165}

A web-app-created backup is a ZIP containing:

manifest.json                                320 bytes
db/chunk-0.bin                             4,346 bytes
opfs/media/<ownerId>/attachments/<file>.png

manifest.json:

{"backupVersion":4,"ownerId":"user_...","mediaPaths":["media/..."],
 "salt":"...","databaseVersion":"31","chunkCount":1,
 "createdAt":"2026-10-25T18:44:59.208Z","name":"Windows11Chrome"}

Key divergences:

Android

Windows

Container

JSON header + blob

ZIP

Version field

formatVersion: 2

backupVersion: 4

KDF

explicit scrypt N/r/p/dkLen

bare salt, no params

Cipher

declared xchacha20poly1305

not declared

Media

inside encrypted blob

separate raw files

Payload

inline

db/chunk-N.bin

Suspected cause

The restore worker detects container type by attempting a ZIP read first. Given a JSON file it fails at EOCD lookup and never tries a JSON path. Separately, the two platforms appear implemented against different format generations (formatVersion: 2 vs backupVersion: 4) that were never reconciled.

Suggested fixes

  1. Sniff the container by first bytes — PK = ZIP, { = JSON — instead of assuming ZIP.

  2. Unify the formats, or have the Android app export the ZIP layout so one parser serves both.

  3. Widen the restore picker's accept filter to include .venicebackup and .venicebackuppack.

  4. Fix the Chrome export path — fall back to a blob download when the File System Access write fails, so failures are visible rather than silent.

Impact

Cross-platform restore is unusable. Users lose chat history, media, folders, Minds and memories when moving between tablet and desktop. Current workaround is manual copy-paste, which drops media and structure.

Attachments

Happy to supply a 12.7 MB sample .venicebackup (passphrase-encrypted, safe to share) plus a web-created ZIP for comparison.

Log in to comment and vote

No comments yet

Be the first to share your thoughts.