Most active commenters
  • arrdalan(7)

←back to thread

Show HN: Open-source private home security camera system (end-to-end encryption)

(github.com)
551 points arrdalan | 13 comments | 30 Nov 24 22:13 UTC | HN request time: 0.638s | source | bottom

I needed a security camera inside my house, one that would send motion notifications to my smartphone and would allow me to livestream remotely. However, I could not find one that I could trust due to privacy concerns. Many of them upload the plaintext of videos to their servers and none is fully open-source as far as I know. Therefore, I decided to use my spare time to build one from scratch. Called Privastead (as in Private Homestead), it uses OpenMLS for end-to-end encryption (between the camera local hub and the smartphone) and is mostly implemented in Rust (except for part of the Android app that is implemented in Kotlin). The system is functional now and I've been using it in my own house for the past couple of weeks.

Based on some of the discussions I've seen online, it seems like there are other users who are also concerned with the privacy implications of home security cameras. Therefore, I decided to open source my solution for everyone to use. If you need a privacy-preserving home security camera, please give it a try and provide feedback. Note that trying out the system requires you to have a supported IP camera, a local machine connected to the IP camera, a server, and an Android smartphone. I have put together detailed instructions on setting up the system, which I hope makes it easier for others to get the system up and running.

In addition, consider contributing to the project. The prototype currently has a lot of limitations: mainly that it has only been tested with one IP camera, only allows the use of one camera, and only supports Android. I'll continue to improve the prototype as time permits, but progress will be much faster if there are other contributors as well.

Show context
VTimofeenko ◴[01 Dec 24 02:04 UTC] No.42285567[source]▶
I've been a happy user of frigate (https://frigate.video) with fully local isolated setup: multiple poe cameras on a dedicated network, coral to supplement on-camera recognition, HA+Prometheus for alerts and smarts.

Excited to see another project, especially in Rust(not for the memes; python env management has bit me a few times when hacking).

One major gripe with frigate that I have is the way it treats detection events as pointers to video files. This makes replicating events off site a major pain.

replies(3): >>42285973 #>>42286293 #>>42287611 #
1. arrdalan ◴[01 Dec 24 04:57 UTC] No.42286293[source]▶
A fully isolated setup on a dedicated network can certainly provide good privacy. A key benefit of Privastead is that it can send the videos to your smartphone remotely using a strong (MLS-based) end-to-end encryption.

And I share your excitement about Rust. :-)

replies(4): >>42286327 #>>42286441 #>>42287177 #>>42287432 #
2. VTimofeenko ◴[01 Dec 24 05:06 UTC] No.42286327[source]▶
The remote access part can be solved by wireguard or tailscale for less hands-on approach. Ntfy.sh/telegram/whatever cool kids use these days for notifications.

This and my previous comment probably amount to a full Dropbox comment now :)

Can you elaborate on the sending video part -- do you transfer the whole file or a link to the file on the server? Curious about the replication piece I mentioned

replies(1): >>42286347 #
3. arrdalan ◴[01 Dec 24 05:10 UTC] No.42286347[source]▶
Privastead uses end-to-end encryption between the hub and the app. The hub encrypts the whole video file and sends it (through an untrusted server) to the app. The app will have a local copy of the video. The hub deletes the video upon delivery to the app. The server never has access to the unecrypted video.
replies(1): >>42286567 #
4. windexh8er ◴[01 Dec 24 05:33 UTC] No.42286441[source]▶
I've been using locally hosted NVRs going on two decades now and so I definitely appreciate another local NVR option. But given the current lack of common requirements (e.g. more than 1 camera), curious if you're seeing any usage outside of your own? As others have mentioned Frigate is filling a nice gap for many, currently. I can only connect to it via a VPN I control and I can easily get notifications via Home Assistant.

I feel as though I have protection of getting the feeds to my phone securely, already. And while I'd love to be able to trust exposing Frigate and making it more accessible, I really don't have a need nor would I as the barrier to entry is already low enough to not impose much friction.

My intent isn't to dissuade you (obviously you wrote it for yourself) but I'd be curious if implementing a more secure transport in an existing OSS NVR that has traction was something you considered?

replies(1): >>42286575 #
5. tehlike ◴[01 Dec 24 06:09 UTC] No.42286567{3}[source]▶
WebRTC might provide a good way to handle this.
replies(1): >>42286603 #
6. arrdalan ◴[01 Dec 24 06:10 UTC] No.42286575[source]▶
Your local setup plus VPN/wireguard is a good design. For me, port forwarding on my router was a no-go due to the increased attack surface. Therefore, I wanted to use the cloud to route the videos and hence I decided to use a strong end-to-end encryption scheme (MLS).

Regarding the limitation you mentioned: I plan to address them. The next task on my plate is to support multiple cameras. :-)

replies(1): >>42291566 #
7. arrdalan ◴[01 Dec 24 06:16 UTC] No.42286603{4}[source]▶
Yes, indeed. Using WebRTC and MLS together should provide good performance and privacy. In fact, Discord recently did that: https://discord.com/blog/meet-dave-e2ee-for-audio-video

It's something I plan to look into at some point.

8. hamandcheese ◴[01 Dec 24 08:52 UTC] No.42287177[source]▶
FWIW, e2ee is a feature that mostly matters to me when I don't own the infrastructure, and my bytes are flowing over someone else's platform.

If I do own all the infra, it seems like a lot of extra effort and complexity in the application which could be farmed out to other solutions (I.e. wireguard).

replies(1): >>42288662 #
9. goodpoint ◴[01 Dec 24 09:58 UTC] No.42287432[source]▶
How is video streamed to the apps? Push notification services are not meant for real time video streaming.
replies(2): >>42287460 #>>42288675 #
10. discordance ◴[01 Dec 24 10:06 UTC] No.42287460[source]▶
RTSP
11. arrdalan ◴[01 Dec 24 14:40 UTC] No.42288662[source]▶
That's right. My assumption is that the server is untrusted and that's why I use end-to-end encryption. This allows me to use any server, possibly even one operated by a third-party service in the future.
12. arrdalan ◴[01 Dec 24 14:42 UTC] No.42288675[source]▶
Push notifications are for notifying the apps of events (e.g., motion). The actual encrypted video (either motion-triggered video or livestreams) are transferred through the server.
13. windexh8er ◴[01 Dec 24 23:27 UTC] No.42291566{3}[source]▶
I actually don't do any port forwarding for my VPN. I end up back hauling over a public termination point on existing tunnels. All tunnels originate outbound in this manner.

Looking forward to seeing your project progress!