1. We did apply to YC a few months ago, but was rejected in the interviews because they felt that the total addressable market was low. We don't know if other VCs will feel differently and we haven't applied anywhere else since. Perhaps paid subscriptions is in a way public funding? :)
2. The rate at which photos are being taken (a trillion a year), we believe that the market is large enough for multiple players. Also none of the existing solutions provide a user experience that we are happy with, so we would like to keep building until we have something that works for us (at least). Also it helps that we are not very motivated by money. As long as we get to build useful things while being able to sustain our lifestyles, we will be content.
--
App:
1. We have been advised by our lawyers to provide no such guarantees. All I can say is that we follow the best engineering practices to make sure that possibility of a data loss/corruption is minimal. And in the unfortunate case that it does happen, we have strategies in place to minimize the damage by applying rollbacks and triggering re-syncs from clients. We will be transparent about any such event.
2. Our infrastructure is agnostic to the data type. Once we have reasonably polished the photos product, we would like to venture into other spaces where E2EE storage + sync is useful.
3. We use BackBlaze as our hot-storage and Scaleway as our cold storage.
4. All files are versioned. File names are not a primary key.
5. Due to the nature of our encryption protocols, we cannot actively look out for illegal content, but we will take down content that violates our ToS[1] when it is brought to our attention.
---
Cryptography
1. The key recovery flow was hand rolled and peer reviewed, since we could not find existing implementations that solved for our use cases. We wanted the recoveryKey to be something that can be shared and rotated if necessary. We have reasoned from first principles and have relied on libsodium for executing the actual cryptographic operations. If you have specific concerns with this, please write to security@ente.io, we would love to engage in a conversation.
Wrapped keys are sent to clients only after verifying a user's email address and 2FA (if configured). This is similar to what most other encrypted storage providers do.
2. The extra layer of authentication was added to serve as an implicit second factor. This ensures that even if your email is compromised, an attacker cannot gain access to an auth-token and trigger API calls that could corrupt your data. Both your email and password have to be compromised for them to authenticate against our servers.
3. If by your password being compromised you mean that all of your encryption keys have been compromised, you will have to re-encrypt and re-upload all of your data. It is difficult to rotate a file key without actually re-encrypting the file.
4. These are seasoned engineers who understand and have used high level crypto libraries to build secure infrastructure at a few unicorns.
---
ToS:
1. We keep it around just to help users recover their data in case they were attacked.
2. I believe that we should be able to offer a takeout for the data that was not in violation of our ToS, but I would like to speak to our lawyers before confirming this. :)
As a fellow founder/eng in the digital consumer privacy space, I can tell you that it remains fringe. And it isn't clear if it will take off in an exponential way anytime soon as, from what I have noticed, VC-backed startups in this space trying to pry out growth have indeed struggled (SilentCircle, as one example). Competing with free [0], as it turns out, may make for a decent-sized lifestyle business, but may not bring in VC-warranted returns (Netflix vs BitTorrent / Spotify vs LimeWire notwithstanding).
Enterprise security and privacy remains very lucrative however, if you are considering pivots :)
Please consider getting ente.io's cryptography reviewed by cryptographers. It does not inspire confidence so much so that I feel ente.io frontends are better used with a tarsnap backend.
I've been thinking of a similar system with e2e sharing of content and I'd love to pick your brain on this if you don't mind :)
- What made you go with libsodium over using the browsers Web Crypto API?
- If you stop sharing an album with someone, do you somehow re-encrypt the collection key or is the recipient still in possession of all the necessary keys to decrypt the data if they get their hands on it?
- Mature libsodium clients were available across the platforms we were targeting. The APIs seemed well documented and turned out to be a delight to consume.
- There are access control checks in place to revoke access to files from removed album participants. But from a cryptographic standpoint, once your keys have been shared (/compromised), the respective files should be re-encrypted.
We don't handle this case right now, have added this to our roadmap[1].
I feel that for our use case of storing and sharing personal photos, this might be an over kill. But I'll let the customers decide. There might be usecases I might not have thought of.
That's exactly the problem I'm facing. Especially if there are multiple shares to the same data it gets tricky.
Love to see public roadmaps in products btw.!
1. We did apply to YC a few months ago, but was rejected in the interviews because they felt that the total addressable market was low. We don't know if other VCs will feel differently and we haven't applied anywhere else since. Perhaps paid subscriptions is in a way public funding? :)
2. The rate at which photos are being taken (a trillion a year), we believe that the market is large enough for multiple players. Also none of the existing solutions provide a user experience that we are happy with, so we would like to keep building until we have something that works for us (at least). Also it helps that we are not very motivated by money. As long as we get to build useful things while being able to sustain our lifestyles, we will be content.
--
App:
1. We have been advised by our lawyers to provide no such guarantees. All I can say is that we follow the best engineering practices to make sure that possibility of a data loss/corruption is minimal. And in the unfortunate case that it does happen, we have strategies in place to minimize the damage by applying rollbacks and triggering re-syncs from clients. We will be transparent about any such event.
2. Our infrastructure is agnostic to the data type. Once we have reasonably polished the photos product, we would like to venture into other spaces where E2EE storage + sync is useful.
3. We use BackBlaze as our hot-storage and Scaleway as our cold storage.
4. All files are versioned. File names are not a primary key.
5. Due to the nature of our encryption protocols, we cannot actively look out for illegal content, but we will take down content that violates our ToS[1] when it is brought to our attention.
---
Cryptography
1. The key recovery flow was hand rolled and peer reviewed, since we could not find existing implementations that solved for our use cases. We wanted the recoveryKey to be something that can be shared and rotated if necessary. We have reasoned from first principles and have relied on libsodium for executing the actual cryptographic operations. If you have specific concerns with this, please write to security@ente.io, we would love to engage in a conversation.
Wrapped keys are sent to clients only after verifying a user's email address and 2FA (if configured). This is similar to what most other encrypted storage providers do.
2. The extra layer of authentication was added to serve as an implicit second factor. This ensures that even if your email is compromised, an attacker cannot gain access to an auth-token and trigger API calls that could corrupt your data. Both your email and password have to be compromised for them to authenticate against our servers.
3. If by your password being compromised you mean that all of your encryption keys have been compromised, you will have to re-encrypt and re-upload all of your data. It is difficult to rotate a file key without actually re-encrypting the file.
4. These are seasoned engineers who understand and have used high level crypto libraries to build secure infrastructure at a few unicorns.
---
ToS:
1. We keep it around just to help users recover their data in case they were attacked.
2. I believe that we should be able to offer a takeout for the data that was not in violation of our ToS, but I would like to speak to our lawyers before confirming this. :)