Show HN: Open-source private home security camera system (end-to-end encryption)
1 year ago (github.com)
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.
Wow!! Very cool project. The reasons you mentioned above are the exact reason that I have not setup security cameras at my house, but this makes me reconsider. Combined with the OSS firmware: https://github.com/openmiko/openmiko this would make a killer combo for privacy conscious individuals.
Glad to hear it. And thanks for the pointer on OpenMiko. It would indeed be nice to port Privastead's camera hub to run directly in the camera firmware. This will make the setup a lot easier: no need for a machine to act as a hub.
The best time to have security cameras is yesterday. Same for a dash cam. Please protect yourself and your loved ones.
I completely agree that security cameras can be a disaster for one's privacy. That's why I decided to build Privastead for my own use in the first place. It's fully open source, so we know what we're getting and what we're trusting. It also uses strong end-to-end encryption provided by Messaging Layer Security (MLS): https://datatracker.ietf.org/doc/rfc9420/
1 reply →
I got hit by a truck a few months ago and a dash cam (well, really, scooter cam) could have shown beyond a doubt whose fault it was. I wish I didn't have to be hit by a truck in order to realize this. If something ever happens you're going to want to have had a recording of it.
5 replies →
Dashcams (including bikecams and helmetcams) are a great idea and AFAIK there's not much of a privacy concern with them as they record to local storage and usually in a common video standard (e.g. mp4).
Hopefully as more people use them, there should be more chance of video footage being available from other vehicles if you're involved in a RTC and don't have one yourself. There's also the protective effect of people uploading bad driving to the police where the police are interested in road crime - hopefully providing the police with a very cheap way of having visibility in lots of places.
3 replies →
Against what does a security camera protect you? I understand for a business that can afford a human being monitoring the feed, it offers protection by reducing response time to potential threats. But for individuals? I thought it was about justice, not protection.
Or did you mean as a deterrent? Which is fair enough (although a fake camera would achieve the same)
1 reply →
Any dashcam recommendations? Last time I looked (last year) there were issues with all the top models I saw recommendations for.
If you need an open-source hardware+fw design for a camera with a motion sensor:
https://github.com/maxlab-io/tokay-lite-pcb
or can be purchased at:
https://www.mouser.ca/ProductDetail/Maxlab/TOKAY-LITE-01?qs=...
Here’s a challenge: Get that thing to record license plates at night.
All the closed source ones I’ve seen set the aperture/exposure based on the average exposure of the frame, so the plate comes out as a pure white rectangle.
Have it sweep through bright and dark when recording at night.
Using a KEM[1] to create a sealed_box[2] type construct would allow for privacy even in a situation where the camera hardware is physically seized. You could also use ML-KEM (aka Kyber), McEliece-KEM and ECDH or RSA-KEM together to provide post quantum resistance.
The traditional symmetric approach (which also has post quantum resistance) in such systems requires the camera hardware to possess the long-lived symmetric key which can be extracted after seizure. Using a ratcheting mechanism (hashing the key every t time) can help - but have no self healing and be vulnerable to recovery from persistent storage (past keys may not be securely erased).
[1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism>
[2] <https://libsodium.gitbook.io/doc/public-key_cryptography/sea...>
Privastead/OpenMLS erases past keys from persistent storage in order not to suffer from the vulnerability you mentioned.
A few years ago I wanted to build a self-sovereign home security system for entire communities and HOAs. We spoke to IBM engineers about scanning video at the edge with machine learning models.
I bought cameras that use RTMP and RTSP, and sent them to my developers. From there, it is not a hard task to use WebRTC (which has end-to-end encryption) to stream somewhere. But my use case involved retaining encrypted videos (every minute and every camera would have a different key) and have a well defined protocol for decryption. To me, the issue of security is not just on one end (recording the crimes) but the other end (mass surveillance, aka who watches the watchers?)
Here is a longer write-up I did: https://community.qbix.com/t/balancing-privacy-and-accountab...
If anyone is interested in working on a startup with me and selling to homeowners and gated communities, reach out to greg at the domain qbix.com
I'd assume that end-to-end encryption would mean the traffic is encrypted between the camera and the app, which it isn't. That would require an app in the camera to support the system (which could be done on many cameras).
I don’t think it’s confusing or misleading. If you’re writing hub software with a corresponding client, then being encrypted e2e between hub and client sounds accurate for the “e2e” moniker. Especially when adding the context of using untrusted servers and notification services.
The traffic is encrypted between the hub and the app. The camera is connected to the hub.
Right, but the "ends" in end-to-end encryption are typically the device producing the content and the device consuming the content. In this case that is the camera and the app.
6 replies →
I have all my untrusted devices (including cameras) on a VLAN that does not have internet access, but is reachable from my main VLAN (but not the other way around). Then I have frigate and homeassistant running on the main VLAN that can connect to the cameras. I use wireguard to connect when I'm not home.
What is the purpose of introducing the untrusted "server" component? Is it intended to run in a different place than the trusted "camera hub" component, such as on a cloud server?
This is key to the claim that Privastead offers superior privacy to other solutions, but it's not explained.
My NVR [1] only uses a trusted server that is intended to be in the same building as the cameras. I similarly recommend not allowing the cameras to access the Internet, as their closed-source software is typically a complete nightmare in terms of privacy and security.
[1] https://github.com/scottlamb/moonfire-nvr
I assume it’s to leverage a) cheap/scalable cloud storage and b) offsite storage for security/ease of access.
Probably, but I'd like to hear the author's take on a key design decision rather than guess. This is also not the only option to achieve some fraction of that goal—another approach would be for the camera hub to encrypt and upload directly to a cloud object storage API (AWS S3 and competitors) and give the client presigned URLs to access it.
My NVR's based on the assumption that you want to record continuously (as called out in the schema design doc here [1]) rather than trust event detection to be perfectly reliable. I've set up other systems in parallel that are based on a different assumption (e.g. Frigate) but have found they miss things, so this is the design I'm comfortable with.
If you are also constrained on upstream bandwidth, continuous recording means you must buy a local hard drive. It costs $100–$200 to buy one that can hold many camera-months of video at good quality, which I find pretty reasonable.
Some folks might want to also upload stuff off-site in case the NVR itself is stolen or destroyed, but I haven't felt the need. There are a bunch of missing features from my system I'd like to add when I have time; that one doesn't make my top 10. YMMV.
[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...
6 replies →
The server only stores encrypted videos until they're fetched by the app. It can't decrypt the videos and hence is not meant as a storage space for decrypted videos.
That is correct. The goal is to be able to use the cloud to host the server without having to trust it. I personally use a cheap DigitalOcean VM.
>It guarantees that only the hub and the mobile app have access to unecrypted videos.
Interesting project! As a Rust implementation for Open MLS, secure end-to-end archival, and a TLS vector, having the DIY home camera setup connect to the internet via a Privastead hub eliminates the need for secure tunneling.
I could see this incorporating facial recognition technology and real-time monitoring.
If you've ever seen eigenfaces, they look like early hominids. One method is principal component analysis (PCA) which isolates the major characteristics of a human face in correlating underlying noise to the most essential features of a face.
Seeing all this focus on security I thought you might be interested in the fact that there are cameras out there with Secure Boot, Axis is one manufacturer I know of that focuses on this feature.
What's a realistic use-case for secure boot on a camera? It's such a corner case...
A friend discovered it when he was wanting to monitor his datacenter and considering local security. A situation where someone has access to your DC and could theoretically erase images of them being there since they also have local access to your cameras.
4 replies →
One use-case I see (for the Vendor) is avoiding the possibility of users to extend the useful life of their device by loading an aftermarket Firmware like OpenIPCam, OpenMiko, or OpenWrt when the Vendor decides it want's the user to buy a new device instead of continuing to use the existing device for more years.
Of course, Axis will say, that they do this to protect the world from terrorism, CP, and human trafficking.
I have bought 3 Eufy cameras that were well reviewed and heavily advertised “no subscription fees, everything is local” as the main features. The hardware itself is fine but the software is rubbish, pure and total waste of every byte used to run it. Not only does it not work half of the time when I try to view the footage or connect to the live feed, but it also often misses motion that it should not - I would often walk in from of my house during perfect weather day and it would just not record any motion. On top of that the mobile app’s primary purpose is to show you ads of Eufy cameras, and they are everywhere in the UI, constant; every other feature is secondary extra that developers spend minimal time in between adding ads. Between unreliability and ads it’s all just so incredibly annoying to use. When you complain about the ads they will turn it down a notch, but not fully, the official response is that “they needs ads to pay for the app”, which is incredibly dishonest - it’s just Eufy product ads - you buy a camera, install the app that is required to use it, and you’re bombarded with ads trying to upsell you more of what you just bought because you using their product costs them. So instead of a simple subscription fee you have adware product with dishonest and misleading messaging, and an app that takes half a gig of space so it can show you ads.
I also remember reporting a bug that there was a constant “new” badge next to their referral button in-app, despite me clicking on it and reading it (which I though it would make the “new” badge go away) - support kindly explained to me that they have new referral program every week, which is bonkers because the only thing that changes is the date.
I did look into alternatives but didn’t see anything I could easily trust more after Eufy, so I’m looking forward to the future where simple open source software will cover this part of market, because private companies so far seem to just give you crap for as my $$$ as they can extract.
Cameras could be built using a single board computer (like the Raspberry Pi Zero, but there are better and cheaper options) plus a USB camera module, and the necessary firmware that could well be just a simple script invoking ffmpeg or similar streaming software; all Open Source.
For example:
https://www.friendlyelec.com/index.php?route=product/product...
https://www.friendlyelec.com/index.php?route=product/product...
https://www.armbian.com/nanopi-duo-2/
Then all video can be collected by applications like Shinobi, Zoneminder, Frigate, etc.
https://zoneminder.com/
https://moeiscool.github.io/Shinobi/
https://frigate.video/
The hardest part would probably be making an enclosure that is solid enough to withstand being exposed to sun, rain, temperature deltas etc. and remain sealed to protect the electronics.
Having had cameras and a couple of breakin attempts for a while now my biggest must-have for these sort of things is:
- reliable human detection (not just motion)
- integration via some sort of API or MQTT etc.
This project appears to have no "smarts" in terms of human detection nor APIs which is a shame. Just pure motion detection on its own is ok, but you're going to pick up all sorts of things that you don't care about.
E.g. I have foxes that run around my garden all night. I don't care about those. But the second a human steps into my garden and starts approaching the house in the night, all the perimeter floodlights are activated, in-house lights turn on, a fake-yet-loud barking dog MP3 starts playing and I get pushover notifications on my phone that won't stop until I ACK them etc (to wake me up).
So far, from personal experience, the most reliable way to stop an attempted burglary in-progress is for lights to switch on from inside as they are attempting to force entry.
> But the second a human steps into my garden and starts approaching the house in the night, all the perimeter floodlights are activated, in-house lights turn on, a fake-yet-loud barking dog MP3 starts playing and I get pushover notifications on my phone that won't stop until I ACK them etc (to wake me up).
Wow this setup seems like overkill for a residential setup. I have lived in “bad” neighborhoods before and have never felt the need to get this kind of setup.
The most I have is a single camera pointed at primary ingress/egress point which is configured to upload to Apple iCloud via “HomeKit Secure Video”.
Yeah I didn't feel the need either until I had two small kids and multiple attempts of people to break-in whilst your 2 year old daughter is asleep upstairs etc.
I actually live in a nice neighborhood and this is the problem I think. I am not especially wealthy, but a lot of people in this area are (and not just a bit wealthy, but like absurdly ferarri-owning excess etc). So while crime generally in this area is low, breakins and robbery is unfortunately high.
I am working on the "run faster than the other person when escaping from a bear" approach. Visible deterrents, then more "active" deterrent in terms of automated lights and dog sounds etc, a solid physical security in the hope that they just try to break in to someone else instead.
Curious, does your MP3 plays "Let the Bodies Hit The Floor" by Drowning Pool?
https://genius.com/Drowning-pool-bodies-lyrics
when I lived closer to the city I ended up with a few cameras covering the street, the driveway, front door..
I caught around a dozen or so car break ins, random trespasses 'looking around' - and a few other things..
Not one of those recordings was going to get police to do anything.
And now that ring / nest etc are everywhere, most people walking the old neighborhood are wearing a hoody covering their head and a 'it's normal now that we had a pandemic mask' of some sort.
Frankly I think it's best to deter with multiple lights and sounds like op mentioned, otherwise you just catch a recording of a minor crime, and it might make you feel good that you could recongnize the person in the video at the corner gas station or bar down the street, but it doesn't let you stop them or do anything to them.
in my small data point experiences, I understand after a hurricane, some parts of Florida had a different police priority announcement, and places like Texas allow the use of force including deadly force to stop a theft of property,
but here having cameras and weapons is not enough, it's actually expected by the 'bad guys'
The best human detection for cctv cameras (in contrast to motion only detection) is an open source project called frigate. You should definitely look it up. It does this better than any paid or free solution I’ve ever come across.
For me the human detection isn't an issue. I only have cameras indoors anyway, i have one outside but it's equipped with a highly zoomed lens so it can see the faces of the people in front of my door. It won't trigger on animals because they don't get up that high.
But in your case I could recommend Frigate, it's got decent detection that can be accelerated with a Google coral TPU. It also integrates really well with home assistant, you could use it for the light triggering you mention.
I personally use Shinobi but it's not really great and constantly asking for money. Especially if you want to use the app.
For me I use Nest cameras with Home Assistant.
I went through various brands of cameras and the Nest ones were the only ones that I could actually rely on. I didn't spend Megabucks but even mid-range local IP cams were very unreliable for RTSP (randomly going offline, super-sketchy partially translated apps for set up/config, frozen streams etc)
I am not concerned about Google's use of my data. I'm not important enough for anyone to want to spy on me specifically. Of all the cloud solutions/providers, I probably trust Google to have the technical know-how but also the public scrutiny pressure to do a general decent job (way more than some random rebadged Tuya service or something "in-house" thing). By that I mean things like e2e encrypted, there won't be employees with just random read access, decent engineering practices, proper security, SREs for uptime, and won't have default passwords/no passwords on some random world-readable S3 bucket etc.
And even if someone did manage infiltrate Google, they'd very likely target someone high-value before me - I doubt anyone would be able to exfiltrate all the data for practical reasons of where to put it but also someone at Google noticing additional exabytes of suddenly outbound data before getting shutdown. I'm working on the (perhaps flawed) assumption that a successful & undetected Google hack would be short-lived. You'd go for someone rich and powerful first, not video clips of me taking the rubbish out.
4 replies →
Privastead relies on event detection by the camera itself. The Amcrest camera that I've used so far only does motion detection (which is all I needed on my end). There are IP cameras, however, that do human detection. I've purchased one of those and plan to integrate it, which would then allow Privastead to provide human detection too.
WebRTC is end-to-end encrypted, too, and unlike OpenMLS is designed for video streaming, so it's great for low-latency live viewing, even over terrible network connections. We are using it in robotic and built a component you can just embed in any web page/app (not open-source, sorry): https://transitiverobotics.com/caps/transitive-robotics/webr... On the device side it supports hardware acceleration on Nvidia, RockChip, and Intel devices with VA-API support (e.g., NUKs).
I appreciate this and will look into it eventually.
Years ago, I used Motion[0] on a pi, laptop and desktop, configured to sftp the motion-activated images to a remote server. I could check the files upon alert and view them in rapid succession as 'video'. It was a clunky setup but worked, aside from the vulnerability of the computers being physically accessible to unwanted visitors - but for this I'd use nohup & physlock to at least prevent quick access.
This relatively free setup had limitations, mostly due to my lack of skills and resources, but it provided significant consolation and I'd bring it with me while traveling, eg using the laptop setup for hotel rooms, etc. The fact that the great Bezosauron et al wasn't involved, did please me.
0. https://motion-project.github.io/
I'm deeply interested in this and it just so happens I only need one hardened IP camera for my home.
Can you point out how your project provides a better security layout than say, Home Assistant? It does appear that there is little concern for encryption between cameras and local networking hubs, but the assumption seems to be that if the device is over a wire it's isolated to the local network, and if it's Wi-Fi it's subject to WPA. So there isn't much desire for additional encryption in that context.
Otherwise, Home Assistant's server/portal is more than capable of encryption beyond the camera's network interface.
If you use Home Assistant in an isolated local network with no Internet access, you will have good privacy. However, I needed to be able to use my camera remotely from my phone. That's when using strong end-to-end encryption becomes critical.
Home Assistant seems to provide two options for remote access: https://www.home-assistant.io/docs/configuration/securing/
One option is to expose your instance to the Internet and using TLS/SSL to connect to it remotely. To me, that's risky since any machine exposed to the Internet is going to see more attack attempts and is harder to secure. The second option is to use their cloud. Here, they explain how remote access through their cloud works: https://www.nabucasa.com/config/remote/#security
They also mention its weaknesses:
"Before we talk about weaknesses, know that we will never abuse any weakness unless forced by a government entity. Our approach has one single weakness that is unavoidable: since we own the domain that hosts the remote connection, we are able to issue our own certificate and man-in-the-middle attack (MITM) remote connections. This would allow us to see all data passing through, including authentication tokens."
Privastead's use of MLS provides strong end-to-end encryption. And Privastead is not vulnerable to MITM attacks due to its secure pairing solution. I plan to write more about the security of Privastead including its pairing solution.
A third option is to set up a Wireguard service and expose the web UI only through the VPN. I use the Wireguard app to connect my phone to my VPN. This solution seems very safe to me. Are there risks I'm not thinking of?
1 reply →
No mention of Tailscale ? It's dead simple.
1 reply →
Does the hub possess ability to delete recording from the server? I understand that hub being compromised is not a part of your threat model but I'm curious if you can preserve the recordings in case it was taken over.
The hub keeps a video until it is received by the app. The hub has a component called the delivery monitor, which processes acks from the app and keeps track of the delivery status of each video. It resends the videos when needed to ensure delivery. Once the app acks receipt of a video, the hub deletes it. The app then keeps all the videos until the user explicitly deletes them. (I've been thinking of a feature that automatically deletes all videos in the app that are older than a threshold, but haven't implemented it yet.)
The server is untrusted and does not have access to the plaintext of videos. It only receives the ciphertext (encrypted video) and notifies the app to download them. When the app fetches a video, the server deletes the ciphertext (in order to be memory efficient).
Yes, the hub is part of the Trusted Computing Base (TCB). That means that we trust it. If the attacker compromises it and takes full control of the hub, then the attacker has unfettered access to the IP camera.
That being said, if the attacker only manages to take a snapshot of the keys used by the hub for encryption (and nothing more), then the forward secrecy and post-compromise security aspects of MLS comes to our rescue. They ensure that the attacker can only decrypt some of the messages (at most a full video depending on what keys are compromised), but nothing before and after that.
I've had some success with Motion (in that i have pictures of a dude ski mask wearing dude looking around the house), which is also open source C (++? no idea). I will look into this but my impression is that work on the edge is done already and what is really needed is some sort of central processor that runs YOLO on several streams
I was thinking about using Pi's for some cameras, but your readme says something about using a Google firebase for passing messages... would email to sms make more sense (if your provider still supports it)?
Also, if I were to set this up behind a firewall, would I need to port forward something so I can access it on the road?
Using Pi's to run the hub is technically feasible (and I do plan on trying it on my end). Port forwarding is not needed. The Pi only needs to be able to initiate a connection to the server.
Google FCM is used for delivering notifications to the app. The server asks FCM to do so when needed.
You are a champion, thank you for this. Will have a look at it when time permits. I've had an irrational and random dislike for anything Rust for some reason... probably because big business seems to like it, but will have to choke on that for this project :)
The reason I chose Rust is that it eliminates memory safety vulnerabilities, which have been a major headache is software systems. Using Rust provides higher security assurance for the hub and the native library used in the Android app. Besides, OpenMLS is implemented in Rust, making it easy to integrate it with Privastead.
Regarding big business, I kind of have the opposite reaction that it has been more community maintained and been the one of the reasons I kind of admired it as a software project. They also tried to make this choice clear by making the tools, documents as accessible as possible.
If you look at the history of Rust, the crates, cargo-team, etc, it is mostly community maintained.
An example of such community-oriented large project is Bevy.
It was only when libraries, rust itself was mature enough, the big tech companies started get involved (apart from Mozilla of course).
Whenever the project gets big and important enough, it will get attraction from large companies. The same is true for C++, as well.
Your comment persuaded me to have a little look at Rust. And I kinda like what I see. Every time I say to myself "I'll never use that tech", I end up using/learning it.
1 reply →
I don't want to come off as negative, but here's an off-the-shelf alternative. My home network has VPN set up that let me access the home video feed securely and privately. The NVR software doing the video recording can process the videos to detect abnormal activities. It will send a push notification to my phone. I then connect to the VPN and view the videos as if I'm on my home's local network, totally private and secure.
This is a reasonable setup. We discussed it in other comments as well
Nifty. Have you considered trying to make the server be able to run as something like a Cloudflare worker?
Not yet. The server is currently fairly simple and doesn't do much other than relaying ciphertexts (and MLS group welcome messages). It should be okay serving one user and several cameras, but is certainly not scalable. I have plans to improve its scalability, but that is not at the top of the todo list. I'll check out Cloudflare workers for sure. Thanks.
I wasn’t actually thinking of scalability. I was thinking that Cloudflare’s Tunnel is a handy, and often free, way to make a LAN service available from outside, and the combination of Tunnel and Workers could make for a nice, easy to deploy, solution.
I can hep you scale it to handle many cameras without gpu
Do self hosted options qualify for insurance discounts ?
Good question. I'm not really familiar with insurance requirements. Privastead simply records videos from an IP camera and sends it to your phone. It does not modify the videos and hopefully that should be adequate for insurance companies.
ZoneMinder?
Using it!
There is also https://shinobi.video/, as another alternative.
Fantastic , thanks
Dude good job. Thanks for this.
Certainly interesting project, but I do encourage people to do more thorough research before starting a new project and claiming they needed to fill a void.
> 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.
There's Frigate [1] which is off-cloud, opensource and self-hosted and it does person detection using GPU or Google Coral. It relays camera streams over WebRTC using ssl and works well with Home Assistant [2], which is your self-hosted off-cloud smart home solution.
Then there's moonfire-nvr [3] which is written in rust and less feature complete than frigate.
And then there's sentryshot [4], another option written in rust.
Interestingly, your project got more stars since you posted it on HN than sentryshot has in total, and they have had a product out since 2021 while yours only support a single camera model and has no object detection.
I suppose this reflects how unknown these option are, which is kind of unexpected since googling "rust nvr" lists them all in the first page.
1: https://frigate.video/
2: https://www.home-assistant.io/
3: https://github.com/scottlamb/moonfire-nvr
4: https://github.com/SentryShot/sentryshot
> The prototype currently has a lot of limitations: mainly that it has only been tested with one IP camera
Since you use rust, you should maybe have a look at retina:
https://github.com/scottlamb/retina
Personally, I use frigate with Home Assistant linked to HomeKit, so I get snapshots & video from frigate straight into my iPhone lock screen as soon as it detects moving people or cars outside my house.
I've got frigate running at 3 sites and use wireguard to log into them and then monitor/review through the browser. Truly awesome technology. Self-hosting object detection and getting alerts is very effective and satisfying.
I'm looking at a similar setup. Mind sharing which cameras you went with?
3 replies →
Thanks for the pointers. Frigate, Home Assistant, and HomeKit were mentioned in other comments and we had some discussions there. They're certainly good setups.
A key design decision for me was using a strong end-to-end encryption scheme between the camera/hub and the app. MLS fit this need perfectly and therefore I came up with the design that is now Privastead.
I was also less concerned with supporting many cameras since all I needed was one camera inside my house. Rather, I wanted a lean solution that I could fully understand and reason about. I will however look more carefully into the NVRs you listed to see if I can borrow some ideas to support more cameras more easily in Privastead.
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.
Have you found cameras you’re happy with? That’s the main thing holding me back is not knowing a good PoE camera to use.
Hikvision and reolink are highly rated onvif ones that support poe, but as long as the camera support ONVIF from there just compare as normal
6 replies →
Reolink have not disappointed me so far. I am using a duo 2 cam watching over the front of the property and a collection of their bullet cams. There's a lot of recommendations on frigate github discussions. Some models indeed have quirks.
On top of decent cameras they also have pretty well-documented API.
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. :-)
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
3 replies →
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?
2 replies →
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).
1 reply →
How is video streamed to the apps? Push notification services are not meant for real time video streaming.
2 replies →
My DIY setup uses cameras on an isolated VLAN that prohibits outbound internet access, RTSP data collected by Frigate[0] with Coral TPU recognition, and alerts via Pushover[1] notifications. My push notifications include an unencrypted thumbnail with a link to Frigate that only works via VPN connection.
Seems like this project offers a lot of what I had to cobble together. Nice work. I like that it offers encrypted notifications although I don’t use Android so not ready for me yet. I don’t like the Google dependency.
[0] https://frigate.video/
[1] https://pushover.net/
Excellent set up, and in fact exactly what I’m using / how I’m set up. In addition for a few IOT type sensors and things like thermostats around my house, I have another vlan as well as a dedicated SSID tagged for that vlan, that only allows Internet access and everything else is dropped for that vlan. (Ie a firewall rule on the forward chain that drops anything in on that IOT vlan, that has a destination address of the private ip ranges: ie dst= 10.x or 192.168.x or 172…. anything locally that needs to access those sensors does so through the cloud/Internet, and for the one or two device devices that need to access them locally I have a fw rule allowing just that devices IP
A fully isolated setup 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.
Privastead does not currently send thumbnails as part of the notifications. Performing proper end-to-end encryption on data in push notifications is a bit tricky and I haven't solved that yet. I do have some ideas on how to make that happen though. Once I do, I plan to add thumbnails to push notifications as well.
And thanks for the pointer on Pushover. I'll check it out to see if it can be a replacement for Google FCM.
Did you look into Scrypted? It is OSS. With HomeKit (which is how I use it) it is also E2EE. I’m not sure if their app is E2EE though, I only use HomeKit.
It’s pretty good and has an extensive ecosystem. The dev can be a bit… feisty though.
It’s very performant and easy to setup. I don’t use the NVR features as I already have an NVR, I essentially just use it for HomeKit integration of my cameras + doorbell.
https://github.com/koush/scrypted
I'm not familiar with Scrypted unfortunately. But thanks for the pointer. I'll have to study it to understand its security and privacy implications. I skimmed the docs very quickly but couldn't find info on their use of encryption.
About HomeKit: yes, HomeKit uses iCloud end-to-end encryption (https://support.apple.com/en-us/102651) and is certainly superior to those systems that don't use encryption at all or just use encryption between the device and their servers. But Privastead has two advantages:
1) Privastead uses MLS for end-to-end encryption, which provides forward secrecy and post-compromise security. iCloud's end-to-end encryption does not. So what does that mean? This is from the link I included earlier:
"If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key."
If an attacker manages to access your password, recovery key, etc., they'll be able to decrypt all your videos (assuming they have recorded all your encrypted videos). Such an attack is not possible in MLS. Similar to the Signal protocol, MLS uses double ratchet and there is not a single password, recovery code, key, etc. that can decrypt everything.
2) The HomeKit framework and iCloud end-to-end encryption are not fully open source as far as I know. Therefore, we simply have to trust what Apple says about their security and privacy implications. That might be okay for some users, but not others. Privastead is and intends to remain fully open source. IMO, being open source is a critical component of any security/privacy solution that would like to gain users' trust.
I’m not sure that 1) is such a win for MLS here.
If I lose my phone, I want to get all my security footage back by entering my passphrase etc on my new phone.
In other words, I want the “encrypted cloud storage” security model from [1], not the encrypted messaging security model from Signal etc.
[1] https://eprint.iacr.org/2024/989
1 reply →
> It is OSS.
Barely. A lot of functionality is gated behind the NVR plugin, which is closed-source and fairly expensive.
> easy to setup
In my experience, it’s easy to set up. But it’s extremely configurable in all the wrong ways and quite difficult to configure in the ways that one might actually want to configure. And the front end is not fantastic IMO: event filtering is extremely weak and scrubbing is bizarre.
> But it’s extremely configurable in all the wrong ways
Damn that feels exactly like my experience with Zoneminder. I’m sure it is decent software under the hood, but the UX is downright hostile to anyone who just wants to get IP cameras to do very basic motion detection to record some full resolution footage, which feels like the major, obvious use case that should be optimized for.
I am thankful for OSS existing in this realm, but why do so many solutions make the same mistakes? Am I crazy in thinking that a good out of the box experience is important? Is some critical part of the formula locked behind private walls? Something else? Genuinely curious.
1 reply →
I've been wishing for a self hosted alternative to cloud cameras. My house was recently robbed and it was incredibly frustrating to know that criminals were literally in my house but not be able to see them due to the general crappiness of modern big tech software.
Seems silly to pay to upload all my video of my own house to who knows where and struggle to download it back with absurdly sluggish proprietary software when I have perfectly good computers here already. I should be able to check my cameras without waiting 10-30 seconds for loading spinners and I should be able to scrub through time instantly instead of waiting for interminable loading every time I touch the seek control.
What camera hardware are people using for custom setups? Is there anything out there that is wireless but with high quality/security firmware and reasonably priced?
I absolutely hate cloud solutions but in this case there's a big benefit in that the robbers can't steal or smash your servers.
They can do that to your networking gear though but by then hopefully their image has already made it to the cloud.
In general I wouldn't expect random street criminals to be able to specifically locate and identify and properly disable a nondescript server in a closet in the middle of a break-in. They're frantically looking for cash and jewelry and portable commodity electronics and firearms. Stuff they can pocket and scram and easily use or fence later.
So you did have a cloud camera system in place but it didn’t record them, or you don’t have one because all available options are shitty?
I do (Nest), and it did record them, but the shitty app made it really hard to see what was happening. Takes forever for the app to load, and it can't show all the cameras at once, and tapping into each camera shows another loading spinner, and then seeking through time is frustratingly slow and imprecise. Then there's the split between old cameras in one app and new cameras in another because Google can't be bothered to update old cameras to work with the new app (which is not any better than the old one anyway, worse if anything). It took minutes longer than necessary to get the full picture of what was happening, and when criminals are rifling through your stuff every second matters. Then after the fact it was a huge pain to get the recordings in a form I could archive and share, and there's time pressure because the recordings disappear after just a few days unless manually archived.
OTOH our alarm system (Ring) performed very well.
1 reply →
Ubiquiti cameras store the data on-prem.
Not open source, and not the cheapest (but not absurd either). App is acceptable.
I read elsewhere that people are upset since Ubiquiti now requires using Unifi hub, at least for initial configuration. Maybe others do too?
1 reply →
If you insist on 'secure' firmware, you're fighting uphill and probably going to be disappointed with the ecosystem out there. Tunnel back to your home network to access cams if that worries you.
I recommend either Ubiquiti or Reolink cameras, both are power-over-Ethernet. Both offer an app that allows connecting back to your equipment. UI will require their Protect software running on one of their local platforms in your house with storage on 1 or more disk drives, while Reolink offers direct storage on microSD on the camera itself, capped at 256GB.
Unfortunately my house is not wired for Ethernet and it's a rental so I can't install it. Wireless is a must and security is obviously important for wireless. But I think you are correct that I will be disappointed by what's out there.
3 replies →
If you're like me and you want something that Just Works -- ubiquiti's offering is fully local and has all the features you'd want including alerts, ml detection (on some first party cameras), app, timeline, etc. They recently started allowing third party cameras, too, so all you need is a Cloud Gateway (USG Ultra is $150) and you're good to go.
The last time I upgraded my networking setup (just as the pandemic started) I went with Ubiquiti, shortly after (before?) they started default forcing you to sign up for their cloud service to use the router, you can switch it to a locally operated mode after you sign up but they bury it in the options. Their networking equipment works great, don't get me wrong, but they don't open source anything. I keep waiting for the full rug pull when sales start to slow because everything they release is rock solid and everything I have is "good enough." I don't feel the need to upgrade for as long as the rug pull doesn't happen.
I am super grateful people are starting to work on open source solutions to this stuff :).
It is reasonable to assume that Ubiquiti has remote access to your fully local data, given that they run the auth server and also push automatically installed updates.
> they run the auth server
I don't think this is true unless you are logging into your router using the ui.com console. Logging in to my UDM POSTs to the local address and works without a WAN connection.
> also push automatically installed updates
I suppose if you've enabled them.
2 replies →
"Privastead uses the Google Firebase Cloud Messaging (FCM)"
I'm am totally unfamiliar with this, but what level of concern that theGoogs pulls the plug on this service about the time you gain traction?
I'm not too concerned with that. As far as I know, almost all Android apps that need to send notifications to the device use FCM. If Google pulls the plug on it, many apps will stop working as intended.
The open source/degoogled alternative to that is UnifiedPush, did you take a look at this?
https://unifiedpush.org/
https://ntfy.sh/
3 replies →