What a cloud provider, sync client, and content hash can still see after you upload an unencrypted file

Dropping a file into Drive is a handoff, not a lockbox

Consumer cloud storage is easy to treat like a safe in the house: the file is still “yours,” so nobody else can open it. After the drop, those bytes have left the folder on this disk. They become an object the provider stores, syncs, deduplicates, and—often—indexes for preview. Tax returns, ID scans, SSH private keys, database dumps, and unredacted customer sheets are all content that should not enter a third-party store and search system in the clear.

HTTPS only covers eavesdropping on the path. It does not decide how the other system stores the file, who holds the keys, what the sync client caches on this machine, or whether a share link returns ciphertext or recovered plaintext. The previous note covered a related handoff: a key pasted into a model session enters history and retention. An unencrypted file dropped into a drive is the same class of exposure. The recipient is no longer a model vendor; it is a storage vendor plus its sync, preview, and deduplication paths. The question before upload is not “is this drive clever.” It is “does this copy contain anything that must not leave this device in the clear.”

This note stays with AWS S3, Google Drive / Google Cloud, and iCloud because those vendors write the layers in public language you can check. A consumer drive rarely spells out “who holds the keys” in the same sentence, but the engineering model is usually the same: TLS on the wire, at-rest encryption with provider-held keys, then thumbnails, full-text search, or instant upload on top. When you change products, walk that vendor’s security page again. Do not paste SSE-S3 or “Standard Data Protection” onto another brand.

HTTPS, at-rest encryption, and zero-knowledge are three different locks

Hearing “is the drive encrypted” as a yes-or-no question drops at least three layers. The first is encryption in transit. The browser or sync client sends bytes over TLS. The path in the middle does not see plaintext. That layer is almost always on, and it is the only thing the address-bar padlock actually promises.

The second is encryption at rest—server-side encryption. AWS’s definition of S3 server-side encryption is blunt: data is encrypted at its destination by the service that receives it; S3 encrypts as it writes to disks in AWS data centers and decrypts when you access the object. Since 5 January 2023, every new upload defaults to SSE-S3 (Amazon S3 managed keys). The algorithm is AES-256, each object gets its own key, and AWS rotates the root key. As long as the request is authenticated and authorized, “there is no difference in the way you access encrypted or unencrypted objects.” A presigned URL works the same for both. Listing objects also does not distinguish encrypted from unencrypted. In other words, this layer protects a stolen disk. It does not mean “AWS cannot open your file.”

Google’s public wording for Drive is similar: files you upload or create in Docs, Sheets, and Slides are “encrypted in transit and at rest with AES256 bit encryption.” Extra confidentiality requires Workspace client-side encryption, and that path needs a work or school account with an administrator who turned it on. Only after that switch does Google write “Google cannot decrypt your files.” The default layer does not. Google Cloud default encryption at rest is more direct: “We own and manage the keys used in default encryption at rest.” If you stay on default encryption, you do not hold those keys and you do not control rotation.

Apple splits default from optional. The iCloud data security overview (published 5 January 2026) says Standard Data Protection is the account default: data is encrypted, and the keys sit in Apple data centers so Apple can help you recover. Only some categories are end-to-end encrypted by default. Apple’s count is specific: 15 categories are always end-to-end, including Health and iCloud Keychain. Optional Advanced Data Protection raises that to 25 and adds iCloud Backup, Photos, Notes, and iCloud Drive. Turn Advanced Data Protection off and the device “securely upload[s] the required encryption keys to Apple servers.” The default is not “Apple also cannot open files in iCloud Drive.”

What a provider can still do when it holds the keys

A provider that can decrypt is not a scare line. It is the premise that default product features need. Online PDF preview, photo thumbnails, OCR, full-text search, and “sort by type” all require some server to see content, or at least a plaintext index derived from it. Google writes the cost of client-side encryption into the same help page: encrypted Docs, Sheets, and Slides cannot be edited in the mobile apps, cannot take Drive comments, have no voice typing, and lose several add-ons; encrypted editor files cap at 100 MB; version history keeps at most 100 versions. Those limits exist for a concrete reason: the server no longer holds a key that opens plaintext.

AWS writes the other side just as clearly. When you share an object with a presigned URL, the recipient’s access looks the same as for an unencrypted object. SSE-S3 does not turn “the person who opened the link” into “ciphertext only.” It stops “who walked away with a disk.” A stolen account, a leaked share link, an enterprise admin pull, and a lawful request all travel the “authorized access” path. Default at-rest encryption lets that path through.

Consumer drives add another layer: the sync client. The file appears in a local sync folder first, then uploads. Even if the cloud later writes at-rest encryption, this computer, another signed-in computer at home, and offline caches on a phone can each keep a plaintext copy. Closing a browser tab does not wipe a file that already landed in the sync folder.

Sync caches, previews, content hashes, and share links are extra copies

Hearing “upload complete” as “only one copy, in the cloud” misses copies on both sides. The first is the sync client’s working copy: the upload queue, retry cache, and leftovers from a version conflict. The second is a derived file the server builds for preview: a thumbnail, a transcoded video, OCR text. Those often live apart from the original. Deleting the original does not always take the derived file at the same moment.

The third is a content hash. Many drives hash the whole file, or each block, and use that digest for instant upload and deduplication: the client sends the hash first; if the server already has it, the bytes do not travel again. That is convenient for an unencrypted file. It also admits that “the same plaintext lives once in the system.” Upload an unencrypted installer or a public PDF and the server can confirm you hold it from the hash alone. Upload the same internal contract from several desks and deduplication still stores one plaintext object. Encrypt on this device first and each run uses a fresh salt and IV, so the ciphertext hashes differently and instant upload misses. That is not a bug. It is the direct result of “the provider cannot see the content.”

Apple publishes a version of this even under Advanced Data Protection. The same iCloud overview says some metadata stays under Standard Data Protection: “checksums of file and photo data are used to help Apple de-duplicate and optimize your iCloud and device storage.” For iCloud Drive, that includes “the raw byte checksums of the file content and the file name.” End-to-end encryption on the file body is not the same as “Apple never sees a fingerprint of the bytes.” Treat any vendor’s instant-upload or “already in the cloud” prompt the same way: a hash match is a statement about content, not only about your account.

The fourth copy is a share link or a team space. Once the link is out, the usual model is “whoever holds the link can retrieve the file.” Combined with the previous section: default at-rest encryption does not rewrite a download as ciphertext-only. What opens in the other browser is recovered plaintext. A “drive link” in a chat group and attaching the file itself have different surfaces. Whether plaintext left your account is often the same answer.

Why a passworded ZIP is often not client-side encryption

“Zip it with a password, then upload” sounds like client-side encryption. Ask which ZIP encryption you actually used. Classic PKWARE encryption (ZipCrypto) is a stream cipher. In 1994, Eli Biham and Paul Kocher wrote in A Known Plaintext Attack on the PKZIP Stream Cipher that the cipher is weak and should not protect valuable data: about 13 to 40 bytes of compressed known plaintext, or roughly 30 to 200 bytes at the start of an uncompressed file, recovered the internal key representation on a personal computer of that era in hours. Modern code lowers the bar. bkcrack documents recovery from at least 12 bytes of known plaintext (at least 8 consecutive), which restores the internal state and then opens the rest of the archive—and other entries encrypted with the same password. Password length does not help this attack. The target is keystream state, not a guess of your passphrase.

Even when a zipper switches to AES, a ZIP can still leave filenames, directory structure, and unencrypted entry comments in the archive header. Drive file lists, search, and “type” filters read that metadata. Treating “the archive has a password” as “the cloud only sees noise” misses both the header and the weak algorithm.

A more common operational miss: the encrypted archive and a readme.txt that holds the password land in the same folder and sync together. The lock and the key go to the same custodian. At-rest encryption and the ZIP password both fail that case.

What changes when you encrypt on the device first

Client-side encryption has a narrow test: plaintext becomes ciphertext before it leaves the device; the passphrase that derives the key is not sent to the storage vendor; the vendor cannot open the file in normal operation. Google describes Workspace client-side encryption as “end-to-end and between clients,” and names “Google cannot decrypt your files.” That is an extra layer an administrator turns on. It is not the default for a personal free Drive. Encrypting yourself, then uploading, walks the same boundary. The keys stay in your passphrase and on your device. You do not depend on whether one drive ships a client-side encryption switch.

A checkable path in the browser is Web Crypto AES-GCM, not a homemade XOR. MDN’s AesGcmParams notes match NIST SP 800-38D: under one key, the IV must be unique every time; the specification recommends a 96-bit (12-byte) IV; the IV need not be secret and can sit in the clear next to the ciphertext. NIST puts uniqueness heavily: reuse of an IV under the same key can allow forgery, and that requirement is nearly as important as keeping the key secret. The authentication tag defaults to 128 bits (16 bytes). A wrong passphrase or a tampered ciphertext should fail closed, not emit broken plaintext.

MakePwd File Encryption Box implements that boundary: chunked AES-256-GCM in the current tab, a passphrase stretched with PBKDF2-HMAC-SHA256 and 100,000 iterations, a fresh 16-byte salt per file, a fresh 12-byte IV per chunk, and output written as IV + ciphertext + 16-byte tag. One file can be up to 5 GB. The default chunk is 1 MB so the whole file is not read into memory at once. Output is .lock or .enc, same binary format. The file and passphrase are not uploaded. Every tool opens with no account, and there is no password vault that stores the passphrase for you. The page answers “can this become ciphertext before it leaves the browser.” It does not upload the file to a drive on your behalf.

Check it here: the canary never enters the upload queue

A slogan that says “nothing is uploaded” cannot prove itself. Split the check in two. First confirm the encrypt step did not send plaintext as business data. Then confirm the object you hand to the drive is ciphertext.

1. Create a text file with one sentence that will never appear in real work, such as canary-cloud-20260902-only-once. The filename can carry the canary too. Use a one-time long passphrase, not a password you reuse.
2. Open the file encryption page in the browser. Open DevTools, switch to Network, and enable Preserve log. Pick the file, enter the passphrase, and download the .lock. Paste the canary in the filter: it should not appear on a request line, in a request body, or in analytics. The passphrase should not appear either.
3. Open the downloaded .lock in a hex viewer or editor. The header should show a fixed magic, not the canary sentence. A wrong passphrase should fail and must not write a broken plaintext file.
4. If you still want a copy on your own drive, upload the .lock, not the original. After the upload finishes, search the drive preview: readable body text should not appear. Do not put the passphrase in the same sync folder.

The first half—request line, body, analytics—is the same check as How to verify browser encryption: prove plaintext never left. This note adds the fourth step: once the object leaves the browser, the layer changes from “local Web Crypto” to “will the drive treat this as plaintext.” The canary should exist only in the original you kept. If it appears in a drive preview or an instant-upload hit, you still uploaded an unencrypted copy.

Practice the boundary on a file box that opens with no account

If you want “become ciphertext first, then decide where it goes,” you do not need to register, and you do not hand the file to MakePwd. Open File Encryption Box, pick a disposable small file, encrypt it with a long random passphrase, download the .lock, and search Network as above. When a person has to remember or receive the passphrase, draw a 6–128 character random string from the Password Generator (default 16; under 8 is flagged as weaker), then consider sending it once with Burn-Link instead of putting it in the same drive folder as the ciphertext. The Burn-Link key sits in the URL # fragment. The reader is public for the recipient.

File Encryption Box does not replace a drive’s own client-side encryption switch, and it does not promise how the other product will scan ciphertext for malware or inspect filenames. The .lock header carries the original filename, so the drive may still see the name. If the name itself must stay hidden, rename the file to something meaningless before you encrypt. A forgotten passphrase cannot be recovered from the ciphertext. Keep it somewhere you control.

FAQ

If the drive says it is encrypted, can the provider still open my files?

Usually yes, under default at-rest encryption. AWS writes that server-side encryption encrypts as data is written to disk and decrypts when you access it; an authorized request treats encrypted and unencrypted objects the same. Google keeps the keys for default encryption. Apple Standard Data Protection stores most keys in Apple data centers so Apple can help you recover. That is not the same layer as “the provider cannot decrypt.”

Is a passworded ZIP enough before I upload?

Traditional ZipCrypto is not. In 1994 Biham and Kocher showed that about a dozen bytes of known plaintext recover the internal key state; password length does not help. Even an AES zip can still leave filenames and directory structure in the clear. If the drive should see only ciphertext, finish authenticated encryption on this device first.

If I encrypt first, do instant upload and online preview still work?

Usually not against the original bytes. Instant upload compares a content hash; the same plaintext encrypted with a fresh salt and IV hashes differently. Preview, thumbnails, and OCR need plaintext. That is the expected cost: if the provider cannot see the content, it also cannot build a preview for you.

Can I keep the passphrase in the same cloud folder as the .lock file?

No. Ciphertext and the passphrase in the same account and the same sync folder hand the lock and the key to the same custodian. Keep the passphrase in a password manager, or send it once with Burn-Link. A forgotten passphrase cannot be recovered from the .lock file. That is the zero-knowledge backup boundary, not a defect.

Three things to remember before the next upload

First, the address-bar padlock and a label that says “encrypted” cover the path and a stolen disk. They do not cover the provider, an admin, or whoever holds a share link. Second, the sync cache, preview derivatives, content hashes, and share links can each keep a copy; an unencrypted upload puts plaintext on those paths. Third, if the drive should see only opaque bytes, encrypt on this device with AES-256-GCM to .lock / .enc, send the passphrase on a different channel, then search Network and the drive preview for the canary.

If the next question is whether the encrypt step sent plaintext as business data, read How to verify browser encryption: prove plaintext never left. When a person must receive the passphrase that opens the ciphertext, read Why a URL hash fragment is a fit place for a key—and when that protection fails and What remains on the server after a one-time secret is read once. This note only draws a line you can write into a conclusion: what can still remain after an unencrypted file enters a consumer drive.