SMF·MEGA-PRO
Can a prompt replace MEGA Pro I?
Cloud storage & backup — end-to-end encrypted storage
Exhibit tracking slip
Verdict
The cryptography here is the accessible part: encrypt in the browser, put the key in the URL fragment so it never reaches the server, and the host genuinely cannot read the file. That is a sitting with the Web Crypto API and there is good prior art. What is not accessible is the resource MEGA actually sells with it — three terabytes of storage and thirty-six of transfer for under ten euros — because that is a bandwidth business.
Exhibit A — The prompt
Received on31.07.2026Build browser-side encrypted file sharing where the server never sees a key.
Stack: a small server (any language) plus a browser client using the Web Crypto API only — no custom cryptography, no third-party crypto library, no rolling your own anything. Object storage or disk behind the server. A domain with TLS.
Upload flow:
1. Generate a random 256-bit key in the browser.
2. Encrypt the file with AES-GCM, streaming in chunks so a large file never has to fit in memory, with a distinct nonce per chunk derived from a random base and the chunk index.
3. Encrypt the filename and content type as metadata under the same key.
4. Upload only ciphertext. The server assigns an id and stores bytes it cannot read.
5. Produce a link of the form `https://host/d/<id>#<key>`. **The fragment is never sent to the server** — that single property is the whole design, and the README should state it plainly.
Download: the page loads with no key, reads the fragment in JavaScript, fetches ciphertext, decrypts chunk by chunk to a stream and saves. Show a clear error if the key is missing or wrong rather than a browser exception.
Controls, all enforced server-side on the ciphertext because the server cannot inspect content: expiry date, maximum download count, and an optional additional password that is mixed into key derivation in the browser (so the server still learns nothing) rather than checked on the server.
Security notes the README must contain, honestly: the link is the credential, so anyone who sees it can read the file, including anyone the recipient forwards it to and anything that logs URLs with fragments; a compromised server can serve modified JavaScript that exfiltrates the key, which is the well-known structural weakness of browser-delivered end-to-end encryption; and this protects against a passive server operator, not against a hostile one.
Abuse controls, because a public upload endpoint is a hosting service for strangers: per-IP rate limits, a maximum size, a total storage cap, and a reporting endpoint. You cannot moderate ciphertext, so you must limit it.
Write tests for chunked encrypt-decrypt round trips including a file larger than memory, for nonce uniqueness across chunks, and for expiry and download-count enforcement.
Do not build sync clients, and do not invent a cryptographic construction.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 terabytes of storage and transfer at consumer prices
- B.2 the sync clients and mobile apps
- B.3 chat, meetings and the rest of the bundle
- B.4 file versioning and a rewind feature
- B.5 somebody else absorbing the bandwidth when a link goes viral
Prior art
Exhibit C — Why people still pay: storage and transfer economics
Because encrypted storage is cheap to write and expensive to run, and the transfer allowance is the line item that actually costs money.
Questions
Is the key in the URL fragment actually safe?
Safe from the server, yes — browsers never transmit the fragment. Not safe from anyone who obtains the link, and not safe from a compromised server that serves malicious JavaScript. It protects against an honest-but-curious host, which is the real threat for most people.
Why stream the encryption in chunks?
Because encrypting a 4 GB file in one operation needs it in memory twice and crashes the tab. Chunked AES-GCM with a per-chunk nonce lets the browser handle files of any size, and it is what makes this usable rather than a demo.
What is the honest limitation of end-to-end encryption in a browser?
The code arrives from the server on every visit, so a hostile or compromised host can hand you a version that leaks the key. Native applications with signed releases avoid this; browser-delivered encryption cannot, and pretending otherwise is dishonest.
Why so much emphasis on abuse controls?
Because a public encrypted upload endpoint is exactly what someone wants for distributing things you would not want to host, and you cannot inspect what you cannot decrypt. Caps and rate limits are the only lever you have.
Related tools
Receipt