How Our Script Encryption Works (And What It Actually Costs)

A script can be private. It might be an unreleased video, a client presentation, or a speech nobody has heard yet. If cloud sync is optional, the honest question is what happens to that text when it leaves your machine. Our answer is that it leaves encrypted, and the server never holds the key. This is how it works, what it costs us, and where the design is not as strong as the marketing word "encryption" implies.

The flow, step by step

• •A random 256-bit key is generated in your browser the first time you sign in. It never leaves the device.
• •When you save, a key is derived from that secret plus a fresh random salt using PBKDF2 (SHA-256, 100,000 iterations).
• •The script is encrypted with AES-GCM using that derived key and a fresh random 12-byte IV.
• •Salt, IV and ciphertext are packed together and base64-encoded.
• •Only that base64 blob is uploaded. The server stores a string it cannot read.

Loading is the reverse: the ciphertext is decoded, salt and IV are split off, the same key is derived again, and AES-GCM decrypts. If the ciphertext was modified in transit or at rest, GCM authentication fails and decryption errors instead of silently returning garbage.

Why these parameters

AES-GCM is an authenticated cipher: it proves the data was not altered, not just that it is hidden. That matters more than it sounds — a cipher without authentication can be tampered with undetected. 256-bit keys are the standard strong size for AES. PBKDF2 with 100,000 iterations exists to make brute-forcing the key slow for an attacker; it is deliberately expensive, which is also why it costs us CPU (more on that below). The random salt and random IV mean that encrypting the same script twice produces two different ciphertexts, so an observer cannot tell whether two saves contain the same text.

What it costs

This is the part most "we use encryption" pages skip. Encryption is not free; it just moves the cost.

• •Server cost: effectively zero extra. We store a base64 string and never run encryption on the server. There is no encryption service to pay for.
• •Client cost: the visible one. Every save and load runs PBKDF2 at 100,000 iterations. On a desktop browser that is tens of milliseconds; on an older phone it can be a few hundred. That is the price of slow brute-forcing.
• •Storage cost: about 33% larger. Base64 encodes 3 bytes as 4 characters, so a 10 KB script becomes roughly 13.3 KB on the server.
• •Bandwidth cost: the same ~33% on every sync, in both directions.

In practice these numbers are small — scripts are text, not video — but they are real, and they explain a design choice: we do not encrypt on every keystroke. Autosave is local; the encrypted upload happens on save, not continuously.

Where the design is honestly weak

• •The key is kept in the browser's local storage. If an attacker can run script on our page (an XSS flaw), they can read that key. Local storage is convenient, not a hardware vault.
• •If you lose the key, the ciphertext is unreadable. There is no password recovery that can bring back the plaintext, because we never had it.
• •This is encryption at rest and on the wire, not full end-to-end messaging. The code that does the encrypting runs on a page we serve, so the security model assumes that page is what we say it is.

The server holding an unreadable blob is the easy part. The hard part is being honest about where the key lives and what happens when it is lost.

If you want the strongest form of this, keep scripts local only — the local storage path needs no cloud at all. The encrypted cloud path exists for people who want sync across devices without handing over readable text. Both are real; pick the one that matches your threat model.