Large File Transfers: Interruptions, Resume and Integrity

Size turns rare events into likely ones. At 10 MB/s, a 50 GB file takes about 5,000 seconds, roughly 83 minutes, and every interruption in that window has to be survived. The common ones:

Storage quotas vary by browser. MDN's storage quota documentation gives Chromium browsers up to 60% of total disk per origin, while Firefox in its default best-effort mode allows the smaller of 10% of the disk or a 10 GiB limit shared by the whole site. A page can ask with navigator.storage.estimate(), and the numbers are estimates, not promises: quotas are computed from total disk size, so the free space can run out first.

“Resumable” is often claimed and rarely defined. A transfer can continue after an interruption only if four things hold:

1. Byte-offset acknowledgements. The receiver acknowledges bytes it has written, not merely received, so the offset it reports after a crash is true. Chunked transfers usually acknowledge chunk indexes, which map to byte offsets.
2. Stable file identity. Both sides must know the bytes after the offset belong to the same file. If the source changed (same name, new contents), continuing would splice two versions together. HTTP solves this with validators such as ETag and If-Range on range requests (RFC 9110); a custom protocol needs a file ID tied to size, modification time or a hash.
3. Persisted state. The offset and the partial data must survive the event that interrupted the transfer. Memory does not survive a page reload; IndexedDB, browser file storage or a partial file on disk does.
4. A transport that can start mid-file. HTTP range requests, or a protocol message meaning “send from byte N”.

Authenticated encryption helps here too. When each chunk is sealed with AES-GCM and its index is part of the associated data, a chunk replayed at the wrong position fails to decrypt instead of silently corrupting the file; how AES-256-GCM works explains why.

A web page cannot simply open a file in the Downloads folder and append to it. There are three main ways to receive a large file, with different limits:

Chromium browsers also offer the File System Access API (showSaveFilePicker), which lets the user pick a destination file the page can write to directly. On a phone, the practical advice is simpler: for files in the tens of gigabytes, receive on a desktop browser or with a command-line client.

Browser sessions

• Byte-position resume within a transfer. If a direct WebRTC connection fails mid-transfer, the encrypted relay continues from the bytes the receiver already holds.
• Survives a page reload. Relay acknowledgements are stored in IndexedDB, so a reloaded page continues the same relay transfer. In Chrome and Edge, a receiving tab closed and reopened within minutes continues the same download, because the service worker keeps it alive.
• Streams into Downloads where that is reliable, otherwise writes to the origin private file system and saves when complete, with memory as the last resort. Streaming is not used on iOS and iPadOS, Firefox for Android or Android WebViews. The 4.3.2 changelog records a 20 GB browser-to-browser transfer with about 100 MB of page memory.
• Ends cleanly when the sender is gone. The receiver ends a transfer 60 seconds after the sender leaves the session, or after 11 minutes without any data, and cleans up a streamed download. A send after that is a new transfer.
• Keeps the device awake where it can, by requesting a screen wake lock during transfers on browsers that support it. It cannot stop someone closing a laptop lid.

Quick-share links and the CLI

Quick-share serves a file from the sender's machine through an HTTPS link. A link refuses to serve a file that changed after the link was created, which gives it a stable identity. srift get writes to a partial file, resumes with HTTP range requests and retries with backoff. The server closes a download whose bytes stop flowing for 60 seconds so the client can resume; for single-use and download-limited links, the resume must come within one hour of the last range request.

srift get "https://srift.app/d/<token>#k=<key>" -o ./big.iso
# several links in parallel (default 4, maximum 16)
srift get <link1> <link2> <link3> --concurrency 8 -o ./downloads/

The send large files page covers the browser flow step by step.

Transport security checks each piece in transit: TLS and DTLS authenticate every record, and AES-GCM tags authenticate every sealed chunk. What they do not cover is the finished file: a bug in reassembly, a write error on the receiving disk, a truncated download that looks complete, or simply the wrong file sent. Only hashing the complete file on both ends answers “is this the same file?”.

Compute SHA-256 (specified in FIPS 180-4) on the sender before sending and on the receiver after:

sha256sum big.iso > big.iso.sha256   # sender
sha256sum -c big.iso.sha256          # receiver: prints "big.iso: OK"

shasum -a 256 big.iso
shasum -a 256 -c big.iso.sha256

Get-FileHash .\big.iso            # SHA256 is the default algorithm
(Get-FileHash .\big.iso).Hash -eq "<expected hash>"

Send the checksum through a different channel from the file, such as a chat message, a ticket or a signed release note. A checksum that travels with the file only detects accidents; one that travels separately also detects tampering on the file's path.

1. Estimate the time from the sender's upload speed: size divided by rate. If it runs to hours, plan around it (see why P2P transfers are slow).
2. Check free space on the receiver: at least the file size, and twice that if the browser stores the file privately before saving it.
3. Choose the receiving side carefully: a desktop Chromium browser that streams to Downloads, or a command-line client. Avoid phones and in-app browsers for files this size.
4. Power and sleep: plug both machines in and prevent sleep for the duration.
5. Network: use a wired or stable connection, stay on one network, and turn off VPN auto-reconnect.
6. Hash first: compute SHA-256 on the sender and send it separately.
7. Test with a small file on the same two devices and networks.
8. Consider splitting the data into several files of a few gigabytes, so an unrecoverable failure costs one part rather than everything.

caffeinate -dims srift quick-share big.iso --wait      # macOS
systemd-inhibit --what=sleep:idle srift quick-share big.iso --wait   # Linux
powercfg /change standby-timeout-ac 0                 # Windows: no sleep on AC power