When you sign up, the client generates a 256-bit key, which is stored at the server after being encrypted with your passphrase which ente does not have access to.
The client encrypts every file you upload using AESCrypt[1] with a randomly generated password. This password is stored at the server after being encrypted with your key.
So as long as you can verify your email address and remember your passphrase, you can download and decrypt your key and files on any device.
When you share files with other users, public-key cryptography is used to share these passwords. When you share files publicly, the client attaches this password to the URL as a fragment.
Q. How is data durability ensured?
Your data is replicated across two different object storage providers across two continents. I’m optimizing for durability rather than cost. Two is one and one is none.
Q. What is the pricing?
$5/100GB/month tentatively.
Q. What happens if your company dies?
The project won't die. I'll open source the server, provide a docker image that can be self hosted, and a script to migrate data to your S3 buckets.
So $60/year. About the retail price of a 2TB external hard disk. Or a 256GB SD card. Or half a dozen 128GB thumb drives.
That's the base case you're up against. It's what all photo hosting sites are up against. But in particular, none of those has a privacy issue. And for anyone who has been around, each is likely to be more reliable than a web based photo solution if history is a guide because the first order economics don't work in the long term.
But history also indicates that anyplace that can store photos online is likely to be used for illegal images such as child pornography and copyright violations. To put it another way, technology is not the critical issue.
Don't misunderstand me, it's cool that you built a system. And there are problems with Google photos. The reason there appears to be an opportunity is because the hard problems are really hard and non-obvious.
> anyplace that can store photos online is likely to be used for illegal images
This is a valid point, and I'll have to figure out a way to craft my T&C such that I'm not held accountable for the decrypted data.
As for the rest, as someone who is okay with paying for convenience and bells and whistles, while I understand your view point, it's hard for me to relate to it. I can only hope for there to be more like me.
But I'm grateful to you for taking the time out to share your feedback. Thank you.
The hosting issue is a matter of criminal law. Terms and conditions don’t matter in that space. They can’t transfer responsibility for breaking the law.
So the unit economics have to cover the costs of dealing with the legal liability. And just for giggles, if you’re making money from hosting illegal content, law enforcement is more likely to pay attention and act with greater force. There’s no low hanging fruit at any kind of scale. If 0.01% of people are bad actors, it’s even money there’s one in the first 5000 accounts - but only if the account holders are randomly distributed among all people. But bad actors are motivated and the cost setting up a free account is asymmetric to the whackamole effort thwarting them.
Do you have any recommendations for how I could work around this?
One thing I could do is to not offer free storage at all, but that would be unfair to the rest.
Another option is to not enable encryption within the free storage tier and to depend on scripts to identify and block accounts uploading illegal content.
But with these approaches I’d be discouraging only those actors who are unwilling to submit their card details.
I took a look at Mega’s terms[1] and their stance is similar to what I earlier proposed. Also, they seem to be thriving by simply being responsive to takedown requests.
Again, I’m curious to know if you think there are more elegant ways to handle this problem.
Nice product you have here. Is there a free version or any plans for free version? Why do you have to say "unfortunate event of a shutdown" when the project isn't even launched? You can maybe put that under a FAQ (like you've done in the comments) but not like this.
That said, I have signed up and I'm looking forward to your project launches ;)
Yes, the plan is to give away the first 1GB of storage for free so that users can try out the product before making a commitment.
> unfortunate event of a shut down
My "shut down strategy" was the one of the first questions every prospective user I spoke to asked about, so I felt the need to clarify. I'll figure out a less intrusive way to get this information across. Thanks again for the comment. :)
Takes up a serious privacy issue which isn't getting surfaced for google photos given its free. There has to be something shady happening behind the scene with google photos data given its offering such expensive cloud storage unlimited free.
1. Any reason for the storage pricing to be significantly more expensive than other cloud storage providers like drive, onedrive?
2. How do you plan to support sharing if the data is encrypted using the user password generated key ?
> There has to be something shady happening behind the scene
Haha, I believe so too.
> more expensive
Not owning data centers definitely is one reason. But I believe that I'm cheaper when compared to other alternatives[1] that are attempting to solve the same problem.
> sharing
When you attempt to share a file, the file-password is encrypted with a freshly generated key, sent to the server, and this key is then shared via public key cryptography (or within a URL fragment in case of a public-share).
15 comments
[ 3.7 ms ] story [ 45.5 ms ] threadI've been building ente to scratch my own itch, and I'm close to launching a beta program with mobile and web clients.
Posting this here hoping to get some feedback and perhaps even my first few users. :)
Q. How is the data encrypted?
When you sign up, the client generates a 256-bit key, which is stored at the server after being encrypted with your passphrase which ente does not have access to.
The client encrypts every file you upload using AESCrypt[1] with a randomly generated password. This password is stored at the server after being encrypted with your key.
So as long as you can verify your email address and remember your passphrase, you can download and decrypt your key and files on any device.
When you share files with other users, public-key cryptography is used to share these passwords. When you share files publicly, the client attaches this password to the URL as a fragment.
Q. How is data durability ensured?
Your data is replicated across two different object storage providers across two continents. I’m optimizing for durability rather than cost. Two is one and one is none.
Q. What is the pricing?
$5/100GB/month tentatively.
Q. What happens if your company dies?
The project won't die. I'll open source the server, provide a docker image that can be self hosted, and a script to migrate data to your S3 buckets.
[1]: https://www.aescrypt.com/aes_file_format.html
If so, how?
That's the base case you're up against. It's what all photo hosting sites are up against. But in particular, none of those has a privacy issue. And for anyone who has been around, each is likely to be more reliable than a web based photo solution if history is a guide because the first order economics don't work in the long term.
But history also indicates that anyplace that can store photos online is likely to be used for illegal images such as child pornography and copyright violations. To put it another way, technology is not the critical issue.
Don't misunderstand me, it's cool that you built a system. And there are problems with Google photos. The reason there appears to be an opportunity is because the hard problems are really hard and non-obvious.
Good luck.
This is a valid point, and I'll have to figure out a way to craft my T&C such that I'm not held accountable for the decrypted data.
As for the rest, as someone who is okay with paying for convenience and bells and whistles, while I understand your view point, it's hard for me to relate to it. I can only hope for there to be more like me.
But I'm grateful to you for taking the time out to share your feedback. Thank you.
So the unit economics have to cover the costs of dealing with the legal liability. And just for giggles, if you’re making money from hosting illegal content, law enforcement is more likely to pay attention and act with greater force. There’s no low hanging fruit at any kind of scale. If 0.01% of people are bad actors, it’s even money there’s one in the first 5000 accounts - but only if the account holders are randomly distributed among all people. But bad actors are motivated and the cost setting up a free account is asymmetric to the whackamole effort thwarting them.
Again good luck.
One thing I could do is to not offer free storage at all, but that would be unfair to the rest.
Another option is to not enable encryption within the free storage tier and to depend on scripts to identify and block accounts uploading illegal content.
But with these approaches I’d be discouraging only those actors who are unwilling to submit their card details.
I took a look at Mega’s terms[1] and their stance is similar to what I earlier proposed. Also, they seem to be thriving by simply being responsive to takedown requests.
Again, I’m curious to know if you think there are more elegant ways to handle this problem.
Thanks!
[1]: https://mega.nz/terms
That said, I have signed up and I'm looking forward to your project launches ;)
> Is there a free version
Yes, the plan is to give away the first 1GB of storage for free so that users can try out the product before making a commitment.
> unfortunate event of a shut down
My "shut down strategy" was the one of the first questions every prospective user I spoke to asked about, so I felt the need to clarify. I'll figure out a less intrusive way to get this information across. Thanks again for the comment. :)
In the MVP, no. But eventually, yes.
> shared albums, who will bear the cost of storage?
Users who own the photos within the album will.
1. Any reason for the storage pricing to be significantly more expensive than other cloud storage providers like drive, onedrive? 2. How do you plan to support sharing if the data is encrypted using the user password generated key ?
Haha, I believe so too.
> more expensive
Not owning data centers definitely is one reason. But I believe that I'm cheaper when compared to other alternatives[1] that are attempting to solve the same problem.
> sharing
When you attempt to share a file, the file-password is encrypted with a freshly generated key, sent to the server, and this key is then shared via public key cryptography (or within a URL fragment in case of a public-share).
[1]: https://crypt.ee