> At this moment you are opening a window of SLIGHTLY lowered security that slams shut after a few hours. For those few hours of preparing your 4 TByte restore,

> At this moment you are opening a window of SLIGHTLY lowered security that slams shut after a few hours. For those few hours of preparing your 4 TByte restore, if an undetected hacker had compromised the one restore server in the Backblaze data center that your job was on, that hacker could possibly get access to your files. But then the reduced security window slams shut, we NEVER write your passphrase to any disk so it has now vaporized and we do not remember it, and if a hacker hacks into our system the following day you are STILL completely impervious. This is the part that security people get hung up on. We have to trust Backblaze [0] to not hang onto the password longer than you say you will, either intentionally (say, "to improve the user experience") or unintentionally ("oh that memory got written to swap and happened to persist on disk for a long time, whoops"). So that's the "malicious" case (maybe some of the above described cases are "benign malice", doesn't matter). There's also the "subverted" case: if the decryption password enters your infrastructure, we have to trust that you have not been popped by an attacker. Whereas, if Backblaze has zero knowledge, and only serves encrypted bits, the _only_ concerns customers have are with durability and availability, which it sounds like you have pretty well in hand from your description of how bits are distributed around your datacenter(s). [0] not just Backblaze but 5-years-from-now Backblaze: people and businesses change.