Hey everyone,
We’ve built an open-source, privacy-preserving alternative to Ring cameras using a Raspberry Pi Zero 2W (called Secluso). It uses end-to-end encryption to send videos from the camera to a mobile app, which is available both in Google Play Store and Apple App Store. We also support Obtainium for people that do not wish to use Google Play.
We’ve put in a lot of effort to make it easy to set up! You can set up our camera on your own Pi in less than 5 minutes with minimal technical expertise using our easy-to-use GUI deploy tool. Here are our setup guide and open source release.
The image shows a Pi in an official Raspberry Pi enclosure that you can use for your camera. We’ve also been working on a HAT for the Pi to add night vision, audio, temperature monitoring for safety, all in a compact form factor. You can see the HAT and an enclosure for the whole camera in the photo.
We’ve been working on this for almost 2 years now, and we look forward to we look forward to seeing what you all think!
In theory, that should be possible. We haven’t tested it.
Isn’t that the premise of the “$4 ubuntu over droplet deployment” option?
Instead of having Secluso-Deploy ssh into some cloud box and prep it up with the server-side software, why not have a container deployment option as well? I get that you want to ensure that the server is publicly reachable for the mobile clients to work on the go, but ultimately (and in all honesty) at this point, that should be a user concern/choice (those more advanced users may be peculiar about running behind tailscale, a home-VPN, a port-routing config, …).
Needless to say, most people here might find it easier to work with containers and build trust in the project by having it run in an isolated environment with limited permissions than blindly trusting that the code is what it says it is and not quietly running a botnet at digitalocean with their PII attached.
I understand your concern. The way we designed the deployment tool was under the assumption people would be using a freshly-deployed cloud single-use server for it (as we assume they have no technical knowledge).
I’m not sure if a container is foolproof. There have been multiple CVEs in the past allowing processes to escape containers through kernel vulnerabilities. Although, I’m happy to put containers on our to-do list if this will help.
As for what the proper solution should be for advanced users, I personally am not sure. I’d need to research that further. We do try to provide things such as reproducible builds, which means if you build the code yourself using our reproducible build script, they’ll match byte-for-byte against our released artifacts. This at least guarantees that it was built from our repository’s code, although it does not guarantee the code itself is safe.
I think something that will help here is our planned third-party security audit, which hopefully will be sometime this summer.