I guess you'd have to do E2EE yourself. (Which _in my opinion_ is the only viable E2EE anyways because I always found it kinda fishy if the party you're trying to protect against also provides the tools you use to protect yourself. But like i said, that's just my opinion.)
>I always found it kinda fishy if the party you're trying to protect against also provides the tools you use to protect yourself.
It actually makes perfect sense the company would want to provide the tools that protect you from them. Take Signal for example, it's a messaging app that does beautiful integration of E2EE into the message transfer product. It's much better than e.g. OTR-plugin developed by Goldberg, Borisov et. al. for Pidgin etc.
What matters is transparency: Does the company allow you to verify their native client does proper client-side encryption, and does that FOSS code have reproducible builds. If yes, then it's much better the company spends some of the revenue from sold space into developing and auditing the client and its cryptographic implementations.
I agree, it's not impossible for a storage provider to also provide trustworthy E2EE. I trust some of these providers as well.
It's just kind of a gut feeling that centralization of power (i.e. possession of the data and knowledge about and control of the encryption mechanism) makes such a service a more attractive target to compromise.
Of course, if you really wanted to get the data of a specific person all you'd have to compromise is the encryption funnel regardless of where the data is stored. But I'm thinking, distributing control over the storage and the encryption is gonna make it a lot harder to do that because there's no single party that knows about both other than you.
Based on who is on their governing board, I think one of the use-cases here is to preserve files you would want to pass on to your descendents. You wouldn't necessarily want to have it cryptographically secured with E2EE.
I have old 5.25" and 3.5" floppies, full of software written by my father during the course of developing his dissertation. He died several years ago.
My original plan was to take whole disk images of it and stash it in the commercial cloud, ... but I'm probably going to stash a copy on permanent.org instead. I have no idea if my descendents would care about it. However, it is a memorial that (if the foundation does what it promises to do), not something I would have to do upkeep after I die.
even cryptographic guarantee doesn't mean shit, the "cryptographic guarantee" is exactly what all the scammy blockchain crypto ICO scammers provided.
At the end of the day, these people can just take all that money, keep some for themselves, and say "ok we tried our best but didn't work out, it was an incredible journey!" and be done with it. and nobody can hold them accountable.
If they really want to do their best to "guarantee" permanence, they should guarantee the debt relationship, so if the forever condition doesn't hold after a couple of years, they will be sought out and collected all the money they took.
> If they really want to do their best to "guarantee" permanence, they should guarantee the debt relationship, so if the forever condition doesn't hold after a couple of years, they will be sought out and collected all the money they took.
What's to say that there would still be an organisation left to pay up the debt?
They'll probably need to hold some funds in escrow for it.
Mmmn, it's just a promise... Doesn't mean it cannot be broken. Not sure it will survive a change of management, too. Here's a primer for you ;) [0]
It's in your power to do your own mangling before uploading. The same with redundancy: don't put all your eggs in one basket (fancy promises or not). Good luck!
OK, "guarantee" is a bit strong. But for example, if the keys are generated client-side and they never see the key, like on tarsnap, then I wouldn't have to take them at their word that they totally promise not to look at my files.
The problems here are searchability, padding to hide sensitive file size, and having to move large containers back and forth to make small edits. If the remote backup is designed around a proper client-side encrypting product, you can have all this easily. If the encryption is done with a plugin, you might accidentally forget to pipe backups through it, or you might misconfigure something. So yeah there's things like cryptomator, but they'll never be as properly designed service with automatic client-side encryption.
The abuse penalizing part is rarely proportional to the income of the company. When the penalty, if you get caught, is just a slap on the wrist, it makes sense to just count is as a fee for making business.
> We will never mine your data, claim your copyright or invade your privacy.
That sounds great and all, but I don't want your word, I want cryptographic guarantees. Are there any?
EDIT: https://www.permanent.org/digital-archives/services/privacy-... doesn't mention anything, so I guess not.