2026-09-03
You asked for all your data. Now it's the most sensitive file on your laptop
Somewhere in the settings of nearly every service you use, there is a button that exports everything it knows about you. Pressing it used to feel like a power move. It is increasingly just the law working: the GDPR's right to data portability has been in force across the EU since 2018, the EU Data Act became applicable on 12 September 2025 and extends the same idea to the data your connected devices generate, and in South Korea an amended Enforcement Decree of the Personal Information Protection Act (Presidential Decree No. 36121, promulgated 19 February 2026) took effect on 20 August 2026, widening the right to have your own data sent to you from healthcare, telecoms and energy to essentially every sector. Three more US states — Indiana, Kentucky and Rhode Island — added comprehensive privacy laws with portability rights of their own on 1 January 2026. All of that is good news, and it has one physical consequence nobody plans for: a file lands in your Downloads folder that contains more about you than any other file you will ever own. This post is about that file.
What actually comes back when you press the button
An export is not a summary. It is the corpus. Take Google Takeout, the best-documented example: Google's own help page walks you through picking products, a file type (".zip" or ".tgz"), and a size cap — "Choose the maximum size archive you want to create. If the data you're downloading is larger than this size, multiple archives will be created," with a 50 GB option offered specifically "to decrease the possibility that your archive will be split." The fact that 50 GB is a plausible answer tells you what kind of object this is. Inside, depending on what you ticked, are years of mail as raw mbox, the original files from Drive, every photo with its GPS coordinates, chat logs, search history, and location history. Korea's new government portal for the same right, 온마이데이터 (onmydata.go.kr), run by KISA under the Personal Information Protection Commission, is built around the same shape: you download your information to your device as a file, or have it sent by email or app.
Then look at how the archive reaches you. Google's default is an emailed link — "We'll email you a link to download your Google data archive" — and the same page notes the archive expires in about seven days and can be downloaded five times. The alternative is having it delivered straight into Google Drive, Dropbox, Microsoft OneDrive, or Box, with a sentence attached that is worth reading twice: "When your archive reaches Microsoft OneDrive, Google is no longer responsible for it." That is not Google being evasive. It is an accurate description of what happens to a file the moment it leaves the system that generated it, and it applies just as much when the destination is your laptop.
Two documented times the archive went to the wrong person
This is not a hypothetical failure mode. Between 21 and 25 November 2019, a bug in Google Takeout put some users' Google Photos videos into other people's export archives. Google notified affected users in February 2020, said fewer than 0.01% of Photos users attempting a Takeout were affected, and, as 9to5Google reported from the notification email, advised: "We recommend you perform another export of your content and delete your prior export at this time." Read the sentence from the other side. For every person who found a stranger's videos in their archive, a stranger's archive contained someone's.
The other case is older and even more on the nose. In December 2018, German technology magazine c't reported that a man in Germany who exercised the GDPR right of access against Amazon was given a download link containing about 1,700 Alexa voice recordings from a stranger's home — alarms, music requests, conversations. He did not own an Echo. Amazon called it, as CBS News reported, "an unfortunate case that resulted from a human error" and an isolated incident. The detail that matters most for our purposes is the ending: the files were later removed from the link, but he had already downloaded them. Once an export is on someone's disk, it is past the reach of the company, the regulator, and you.
The regulators already told you to encrypt it — quietly
The EU's own guidance on data portability anticipated this exactly. The Article 29 Working Party — the group of national data protection regulators that preceded today's European Data Protection Board — closed its Guidelines on the right to data portability (WP242 rev.01), adopted 13 December 2016, with a section headed "How can portable data be secured?" Its final paragraph reads, verbatim: "By retrieving their personal data from an online service, there is always also the risk that users may store them in a less secured system than the one provided by the service. The data subject should be made aware of this in order to take steps to protect the information they have received. The data controller could also, as a best practice, recommend appropriate format(s) and encryption measures to help the data subject to achieve this goal."
That is the regulator saying, in 2016, that the archive is safer inside the company than in your Downloads folder, and that somebody should tell you to encrypt it. The "best practice" half never really happened — the export screens of the world's largest services do not recommend encryption measures, and the advice is left to reach you some other way. This is the other way.
Closing the window: six things to do in the right order
First, decide where the download lands before you request it. If your Downloads folder sits inside an automatically synced tree — OneDrive's Known Folder Move, iCloud's Desktop & Documents, a Dropbox folder — the plaintext archive uploads itself to another company the second it finishes downloading, and you will never see it happen. Point the download at a folder nothing syncs. Second, prefer the plain download over "deliver it to my Dropbox," for the reason Google states outright: once it reaches the third party, it is under that party's terms. Third, encrypt it in the same sitting, while you still remember it exists. Fourth, delete the plaintext original afterwards and empty the trash — knowing that deletion is not erasure, which is exactly why the window matters and why you want it short. Fifth, let the download link expire on its own schedule and do not forward that email to yourself "to keep it handy"; a live link in a mailbox is a second copy of the archive with no passphrase on it. Sixth, only now decide where copies go. Once the archive is ciphertext, a backup drive, a second machine, or a cloud folder are all reasonable places for it, because none of them can read it.
What encrypting the archive honestly does not fix
Five limits, stated plainly. First, it does nothing about step 2 going wrong in either
direction. If an archive you receive turns out to contain someone else's data, encrypting it is
not a remedy — report it to the service and delete it. And if your data went to a stranger, no
action of yours reaches their disk; that is why the Amazon case ended the way it did. Second, it
does not touch the copy still held by the company. Portability gives you a copy; it does not
retract theirs, and their breach risk is unchanged. Third, it does not protect the archive while
you are actually using it: if you extract the mbox to search ten years of mail, that extracted
mail is plaintext on your disk for as long as the job takes, and the tidy-up is part of the job.
Fourth, size is a real constraint, not a footnote. NearSeal works in your browser's memory, so it
accepts files up to 500 MB each and 500 MB per batch on a desktop browser, and 50 MB per file
(100 MB total) on phones or devices reporting 4 GB of RAM or less. A 40 GB Takeout is simply not a
job for a browser tab, and we would rather say so than have you find out at 90%. For an archive
that large, encrypt it with the command-line age tool (age -p bigfile.zip)
or use full-disk or encrypted-volume encryption on the drive it lives on — and note that because
NearSeal can read and write real age files, the two are the same format, not competing ones.
Fifth, there is no recovery. Forget the passphrase and the archive is gone, which for a
once-in-a-decade export you may never think about again is a genuine risk: put the passphrase in
your password manager the moment you create it.
Where NearSeal fits
A tool for locking down the single most revealing file you own should not be one more place
that file travels to. NearSeal runs entirely in your browser: the archive and the passphrase never
leave your device, there is no account and no upload, and you can watch the network tab confirm
that nothing is transmitted — which for this particular file is the whole point, since uploading
your complete data export to a website to "protect" it would be a spectacular own goal. The
default format is AES-256-GCM with the key derived from your passphrase by PBKDF2-SHA256 at
220 iterations, and the container's header is bound into the authentication tag, so a
tampered or corrupted archive fails loudly at decrypt time instead of quietly handing you altered
data. If you would rather not depend on this or any website in five years, there is the opt-in age-encryption.org format: age files use scrypt and
ChaCha20-Poly1305 rather than AES-256-GCM, and they open in the official age CLI, in
rage, and in any other age-compatible tool. Decryption recognizes either format by
its bytes, not its filename. Two things NearSeal is deliberately not: it is not storage — where
the encrypted archive rests is yours to choose — and it is not a recovery service. You asked for
your data. Keeping it is the part that is now yours.