[falcolas]

> It seems like every potential solution has some major caveat that someone will invariably point out as making the solution useless.

You have to come up with a threat model. You have to decide what threats are the most important to you.

I'd group them into three domains, based on the amount of effort involved in mitigating the threat. From the most work to the least: Threats you absolutely and utterly must avoid at any cost and effort. Threats you want to avoid, but you're not willing to the extent of fighting a state-level actor. Threats where it would be nice to have them mitigated, but it's not worth exceptional effort or cost.

For your backblaze (BB) example, your threat is "BB's client can't be trusted" and the sanctity of the data falls in bucket two.

To mitigate your distrust of BB's client, you'd want to make sure it never sees unencrypted data. And so, you'd do something like encrypt the data with your own key, and then send it to BB. You'd want to use a second computer (or a dual boot system) to ensure that the OS which hosts BB's client is not running when the encryption is happening, and share the resulting encrypted binary files with the computer that will do the upload.

The keyboard on the encrypting computer could still be a threat, but that's getting into the "state-level actor" levels of effort to counter.