Hi there,
I’ve been part of the team of zeitkapsl for more than a year now, and wanted to quickly introduce the service I have helped to build.
As the title suggests, zeitkapsl is a service for storing, organizing and sharing photos & videos end-to-end encrypted.
what zeitkapsl offers
end-to-end encrypted storage for photos and videos
automatic backups from Android and iOS devices
native and open source apps for Android, iOS as well as a web-app and Desktop GUI and CLI clients for bulk import/export
shared albums/collections encrypted with a password or sharing key in the URL fragment
anonymous uploads to a collection (allows you to create an album for an event and let people without a zeitkapsl account upload photos and videos)
on-device indexing of photos → search for location, date, objects and text
replication across two data centers in the EU
easy-to-use UI/UX for non-techies
a 30-day free trial, no CC required
why zeitkapsl in particular?
zeitkapsl is based in the EU and fully under EU jurisdiction. The GDPR applies to us while the CLOUD Act does not. We also try to go for EU based services in our whole supply chain whereever possible (we also host our source code on codeberg instead of github)
Our crypto architecture is solely based on symmetric cryptography. Something you might want to take into consideration in case (future) quantum adversaries are part of your threat model (zeitkapsl does not officially claim to be post-quantum secure, since we have not let an indepentent expert evaluate this claim yet. My personal understanding is, that as long as the user chosen password is of sufficient complexity, the cryptography we use should be resistant to currently known quantum attacks. Would be interesting if anyone in this community has opinions on that)
zeitkapsl offers fully native mobile apps. This might be a personal preference, but I usually feel like apps built on hybrid cross platform frameworks like Flutter, which some of our competitors use, don’t feel as slick as native apps.
We built privacy preserving reverse geo-coding into our apps, so you can search your photos for country, county and city if they have a GPS tag in their metadata
We are bootstrapped and independent, we do not take funding from US tech giants or venture capital
It is for metadata at least (IP addresses in access logs, payment information etc)
Makes sense. I focused on the compairison with listed alternatives since it is required by the self-submission process, I’ll try to shift the focus of the post
Right I see where you coming from but that stage was done before posting here and i thought it was interresting enough to let you open a showcase post.
One of them is Hetzner in Falkenstein, I’ll have to check with my colleagues for the other one, will get back to you with that
We are always on the lookout for more options. Unfortunately, there isn’t a lot of options for affordable object storage if you want to avoid the US hyperscalers. As we scale, some new options will become economical.
For one, object lock on the storage providers should protect against a lot of attacks like that. But yes, for a while we had our cold storage backup on a large hard drive in our office, we will backup to a dedicated storage box that is just used for backups in the future
yeah, the name
[ˈt͡saɪ̯tˌkapsl̩] (literal translation would be “time capsule”, so like that, just more German (kapsl is actually pronounced quite similar to “capsule”, the “zeit” like in “zeitgeist”)
EU chat control is now being pushed through to fight “child sex abuse”. What’s going to happen if tomorrow EU decides that zeitkapsl and similar services are actually being used to store pictures and videos of bad stuff that must be monitored? Would zeitkapsl not be covered under Regulation to Prevent and Combat Child Sexual Abuse - Wikipedia and potentially be forced to put in backdoors?
Luckily, it seems like chat control, at least in the form of mandatory client-side scanning, is off-the-table for now (I would like to believe us co-signing this open letter made the german government finally decide against the draft ). Implementing back-doors is out of the question for us in any case (one of the reasons why we decided to open source the apps was to actually commit to this promise)
To my understanding, the CLOUD act is not irrelevant.
Ente does backup encrypted data & incl the encrypted master key which if handed over can later all be decrypted when the end user is coerced into giving their Ente passphrase (a key stretched derivation of which encrypts the master key).
The user might think they have deleted all the data but Ente could have already shipped that to the US govt.
There’s a reason Signal took so long with backup and recovery. They built this elaborate, super expensive, distributed system with split keys to precisely hold off such actors and threats.
If the community is folks giving their unwarranted opinions… no better, me thinks. That said, bashing a competitor on your launch day leaves a bad taste, yeah.
Quick clarification: My intention was not to bash anyone. I have huge respect of what e.g. ente built. I just misinterpreted the self-submission guidelines and thought the post had to center around why one would use the posted/proposed service over the recommended ones.
Also, to set this straight, we didn’t launch today, but in spring this year, I just introduced it here today
This is complete FUD. It is highly unlikely that anyone will be able to decrypt your master key. And if they are capable of doing that they will just as easily have a way in the european data centers which both services use.
And yes this my own opinion and not that of Ente ( not sure how you got that impression?!)
Another question is indeed why you have not used KDF for the master key and account password. Have some secret file is surely not user friendly and will probably lead to some availabilty issues or is this only targeted at tech savy?
Also it seems 2FA is not part of the set up. I would recommend to make this part of sign up.
We have not yet completed a formal third-party audit. We did have an audit by a befriended company, but did not request a formal report for that since we want to do a real independent audit anyway. (That is also the top voted item on our roadmap)
That’s what we do. The secret file is just a backup of the master key for recovery, in case a user forgets their password.
Regarding 2FA being required, I’m not sure whether I agree that this makes sense. The password is the whole basis of the cryptographic protection. 2FA is at this point just a last resort protection that prevents you from logging in in case you got the password, but I do not believe it adds fundamental protection in a way that outweighs the hassle for people who don’t have a OTP-manager.
Passkey support is not planned for the near future, but we do want to consider them for the medium term
). Implementing back-doors is out of the question for us in any case (one of the reasons why we decided to open source the apps was to actually commit to this promise)
