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.
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/
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.
> Instead of video, what if our bodies and property emitted points clouds all the time
If instead of practical and widely available technologies we are discussing scifi concepts which have no realistic prospect of materialising then why not wish for a force field impervious to trucks? Or even better, lets skip the whole middleman and wish for point to point teleportation for all cargo eliminating all dangers and externalities of trucks.
because I believe there is a realistic prospect of materializing and it would increase accountability for many actions where its currently impossible even with the burgeoning ubiquity of video
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.
A number of dash cams now use cloud storage. If anything, when I last purchased I had to go out of my way to find one with decent enough video that also stays local.
That's surprising - I would guess that cloud storage would add to the price of them as they'd need a mobile data connection and presumably monthly costs. They must be designed for fleet management where you don't necessarily trust the driver to not delete footage.
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)
It can be all of that and more. And in my case, if someone breaks into your house and steals your stuff, the police will not care because you don't have any evidence. And then your insurance doesn't believe you either and threatens to drop you.
And if someone is trespassing and about to commit a crime, you can be notified (yes even as an individual, with your own private self-hosted solutions even) immediately so that you can call police or deal with it however you want, especially if you're not home.
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).
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).
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?)
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.
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.
Correct, that would be even better, but I didn't have control over the camera firmware. Someone mentioned OpenMiko, which I plan to investigate and see if it can allow me to effectively run the hub inside the camera itself and achieve what you are referring to.
I'd probably change that in your readme then, this is usually called something like encrypted in-flight or transport encryption.
End-to-end encryption is a pretty specific term and clearly not what is done here. Even if you use protocols designed for end-to-end encryption that does not matter if the protocols talk with an intermediary (the hub) that decrypts the traffic.
For example, if signal still used the signal protocol but decrypted the messages on their server that would not be acceptable to be called end-to-end encryption.
Agreed, transport encryption is the term to use for this model which is a great model anyway.
You can use e2e if the data-at-rest (e.g., video) file(s) are also 100% encompassing the encrypted in both the camera and the remote server, as well as the mobile app and remote server.
From the client-side, this E2E means no raw data are exposed over network nor in remote storage and that keys are required to view the raw data at either endpoints.
In today's parlance, the undefined portion of E2E is whether the local storage is encrypted as well. Some will argue on this point. Future may (and should) tighten this E2E as well.
The end-to-end encryption part is clear IMO: it's between the hub and the app, both of which are trusted. This is different from an untrusted server decrypting the messages.
The point of end-to-end encryption to me is that I don't need to have a trusted intermediary (in this case the hub).
Anyway, either way it's probably good to include something about how the traffic between the camera and the hub is completely plaintext and unencrypted and includes the password to the camera (unless I'm missing something), so even in your model it's not just the hub that is an additional point that needs to be trusted, it's also the whole network that they are on. That's probably at least a router and might include many other devices, sometimes quite untrusted.
Since some cameras support adding TLS/HTTPS it would be good to add support for that by not hardcoding http for the onvif endpoints. I think FFMPEG supports rtsp over tls out of the box.
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.
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.
I haven't designed Privastead for continuous recording/streaming. It's mainly to receive motion/event-triggered videos and occasional live streaming. The usage model is more like Ring cameras.
The question of "What is the purpose of introducing the untrusted "server" component?". Looks like you've since replied to this, but it wasn't here or I didn't see it when I dropped the parent comment. The reply also doesn't compare alternatives such as direct use of an object store API. I've fielded a lot of user support questions about installation and would really hesitate to add that extra moving part if it's not strictly necessary.
Overall, we must be coming at this with quite different expectations of what a NVR should do. Not just this but also "when the app fetches a video, the server deletes the ciphertext (in order to be memory efficient)". Some installations of my NVR software are multi-user; I personally use it from multiple devices; etc. So the idea the whole pipeline exists just to transfer event videos to a single Android device results in a system that I would not find useful.
There certainly is space for different approaches. E.g. Frigate's approach is quite different than Moonfire NVR's but obviously is useful in a lot of ways to a lot of people. But my take is that Privastead's approach is going to be pretty niche, and the claim that other NVRs don't offer strong privacy assurance using "end-to-end" (on-prem server to client) encryption is untrue.
Also, I find it inaccurate to say it's mostly implemented in Rust which "provides higher security assurance for the hub". The Amcrest camera you've chosen is essentially developed by a hostile nation-state, and the protocol code you're using to interact with it (ffmpeg) is all written in C, which I find incongruous with the privacy/security goals. In fact, ffmpeg's RTSP and Matroska code is probably the majority of lines of code in the system.
Yes, we have different approaches/designs. In fact, I don't even of think of Privastead as an NVR solution. The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.
And my main comparison has been with security camera solutions that use their cloud solution to transfer videos (e.g., Ring). I think an open source solution that uses MLS and treats the cloud as fully untrusted is a superior alternative.
Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.
Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)
> The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.
Yeah. I'm also frustrated with cameras in general. I've commented on this a few times here before, [1] but tl;dr: I don't even know what camera I'd recommend even if I had the perfect open source firmware to flash onto it easily.
> Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.
Okay, interesting, yeah that sounds like a significant step up for most folks.
> Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)
Patches very welcome. It could use more attention than I've been able to give it recently but likely will interact well with your camera model as-is.
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.
>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.
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.
So someone is going to access your camera, power it off, flash a custom firmware to it that they have themselves written that gives them backdoor access to the camera, somehow set it up so that it also has network access that you cannot see on your firewall or network monitoring tools? Then they login to your servers and hope that you don't have any logs enabled that automatically get sent off to a cloud server somewhere. Sounds like your friend has some three letter agency enemies.
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.
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.
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.
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.
Hmm I don't trust Google at all to be honest. I don't even use a Google account on my android phone anymore.
I do have some ring cameras but they're only looking at my front door and I've cut the microphones out of them (they're incredibly sensitive, I could literally hear myself word for word two rooms away).
Most of my cams are TP-Link used in local mode with internet access blocked.
> And even if someone did manage infiltrate Google, they'd very likely target someone high-value before me
The risk isn't just an evil insider infiltrating Google.
It's also that a lot of home security companies are in the business of having a friendly relationship with the authorities. So if the cops were investigating a fender-bender down the street and they ask Google for your videos? Better hope that living room camera doesn't show anything you wouldn't want the cops to see, because it's getting handed over.
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.
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.
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.
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?
That's definitely better, if done right. I still prefer to avoid port forwarding on my router if possible. The fewer attack surfaces I have to worry about, the better.
Right? All of this seems like trying to solve the wrong issue. Solve VPN routing with a routing solution, solve stream collection and processing with something like Frigate. I run ML models locally on a GPU and get a notification through MQTT/HA/Tailscale to my phone when the local stray cat arrives for dinner. What else do you really need?
I don't buy the cheap storage argument, trading an upfront cost of maybe $100 for all that complexity. And you can still keep archives - and even a reasonable UI - with some off the shelf FUSE driver. Or, less janky, a cron script running rclone or whatever.
Cool project, I just don't see people migrating to it.
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.
If you want to watch a talk from a person with good presentation skills on this point, I would recommend the following video: https://youtu.be/cWSh4ZxAr7E?t=3314
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.
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.
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.
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.
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.
Those Amcrest cameras are rebranded Dahua products with the logos changed. Right down to the firmware bugs and confusing UI. They’re actually great cameras for the money, but man do I loathe their quirks sometimes.
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.
I can second Frigate and welcome any work in this space, so nice work OP will have a look. For others asking, I have found so far Hikvision POE PTZ domes like DS-2DE2A404IW-DE3 have been reliable, depends on your budget. I have cams themselves fully locked down from internet and on a separate subnet on the local net. OPNSense is also a friend here. I would love some OSS firmware for these cams. For remote, I find ZeroTier to Frigate & Home Assistant machines is all I need. I get why others WireGuard too. YMMV
Search for "Hikvision compromised" though. The results are damning. I suppose there's not much of a concern if using a proper firewall on a managed network, however.
Even if it does have phone-home functions, why does the camera itself need internet access?
IMO, audit the hardware for wireless radios (PoE cameras shouldn't have them), and put them on a camera-only VLAN that can only talk to the video server.
Maybe not suitable for super secure TS locations, but in general should be fine for 99% of situations.
I think if you've got total control over them, not a problem
compartmentalising. Problem is, they're like loitering munitions, next
person comes along and connectes them up to a router or misconfigures
a firewall... Much as I hate e-waste sadly best place is in the bin.
They're cheap but, easy come easy go.
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.
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
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.
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?
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. :-)
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.
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).
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.
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.
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.
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.
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.
Interesting. I think the usage model provided by Privastead is reliable enough (at least for me). I have access to my videos on my phone. If losing the phone is a concern (which should be rare), we can easily add a feature that keeps a copy of the files in the hub too.
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.
I suspect there’s a tendency by the kind of developers who make fancy open source projects to expose all the awesome nerdy power of their software. Have three different motion detectors? Expose all of them! Make them plugins! Have “extensions”! Have components provide “things!” Make a UI for all of that! It’s especially nifty when the UI looks just like the code structure.
But making a good UI for defining object detection zones is hard, so the very first thing that works at all sticks. Or, once you’ve carefully optimized by using the camera’s built in motion detection and having all the streams you could want, supporting software motion detection is an afterthought, and making it configurable in any useful manner is even more of an afterthought. After all, all the cameras you actually use personally have built in detection that works well and also have so many built-in RTSP streams that you never actually had to optimize for the experience of using a camera with a single stream, a somewhat defective implementation of ONVIF, and entirely unusable motion detection. So you make it work, but only using plugins and extensions, and it never becomes pleasant.
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?
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.
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.
Yeah my ring alarm worked well too when my place was broken into. It scared them off, they broke down the door but didn't actually come inside.
Unfortunately that prompted to police to be less than helpful (they considered it vandalism instead of a burglary and didn't even take prints). And because they didn't enter the house my cameras didn't see their faces so I couldn't try to track them down on my own either. But at least my stuff was ok.
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.
Unfortunate. Reolink even has wireless cameras, but they will require a DC input, so you'd need an outdoor electrical outlet if you can't drill any holes and sneak either a power or UTP Ethernet cable.
Given the strict physical requirements, you might be looking at battery-backed wireless cameras of the type often found on Amazon, but afaik they will never offer the local storage or control you want.
I will say that surprising things can be accomplished with small drilled holes and a fishtape. Your risk tolerance and how nice the rental are obviously very important factors.
I used a Reolink Argus with a battery and Wi-Fi connection. The one I used is probably EOL now, but a quick look at the site shows even solar chargeable options. So, it is possible.
I've got a Reolink Argus 2E which look like it's been replaced by the 3E, but it works great without any wired connection to the house. I've got it solar powered and strapped to a tree, unprotected by the elements. 2 years and still working.
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.
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.
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.
Sure, just wanted to tell you about it, as this seems to be defacto standard for foss android apps, for example most if not all https://matrix.org clients use it for push notifications (when you use their de googled build, or don't have play services) available. I also use a Signal fork with UnifiedPush and have some server alert scripts which post to my self-hosted ntfy instance, and the ntfy app itself will display them (otherwise for the Messengers, the Notifications will be from the messenger app itself, as these apps get "notified" aboout a notification and then do their own thing).
it's not about trusted/untrusted as in what will they do with the data. it's entirely about will the service be available long term or if theGoogs will deprecate it in the future.
I have no skin in the game of push notification infrastructure, but we've seen plenty of ShowHNs where a critical part of the Show is a total dependency on a 3rd party shim. While this isn't something like a dependency on a Twitter API that suddenly got yanked, it is still something that devs should really consider. Especially given theGoogs' track record.
Maybe this isn't the case it is a library deeply embedded in the Android ecosystem, but anytime a ShowHN mentions a dependency on theGoog it sets of the SpideySenses
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/
You should do a ShowHN on it!
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.
Instead of video, what if our bodies and property emitted points clouds all the time
where visual representation can be recreated, similar to how LiDar does it
I’m not sure if thats more or less data to store, but it can show the depth and direction of intrusions into your space
> Instead of video, what if our bodies and property emitted points clouds all the time
If instead of practical and widely available technologies we are discussing scifi concepts which have no realistic prospect of materialising then why not wish for a force field impervious to trucks? Or even better, lets skip the whole middleman and wish for point to point teleportation for all cargo eliminating all dangers and externalities of trucks.
because I believe there is a realistic prospect of materializing and it would increase accountability for many actions where its currently impossible even with the burgeoning ubiquity of video
Please tell us more. How do you imagine what do you say being possible?
Don't you just love the idea of giving Big Tech and law enforcement literal x-ray vision. That'll go down very well...
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.
A number of dash cams now use cloud storage. If anything, when I last purchased I had to go out of my way to find one with decent enough video that also stays local.
That's surprising - I would guess that cloud storage would add to the price of them as they'd need a mobile data connection and presumably monthly costs. They must be designed for fleet management where you don't necessarily trust the driver to not delete footage.
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)
It can be all of that and more. And in my case, if someone breaks into your house and steals your stuff, the police will not care because you don't have any evidence. And then your insurance doesn't believe you either and threatens to drop you.
And if someone is trespassing and about to commit a crime, you can be notified (yes even as an individual, with your own private self-hosted solutions even) immediately so that you can call police or deal with it however you want, especially if you're not home.
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.
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).
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.
Correct, that would be even better, but I didn't have control over the camera firmware. Someone mentioned OpenMiko, which I plan to investigate and see if it can allow me to effectively run the hub inside the camera itself and achieve what you are referring to.
I'd probably change that in your readme then, this is usually called something like encrypted in-flight or transport encryption.
End-to-end encryption is a pretty specific term and clearly not what is done here. Even if you use protocols designed for end-to-end encryption that does not matter if the protocols talk with an intermediary (the hub) that decrypts the traffic.
For example, if signal still used the signal protocol but decrypted the messages on their server that would not be acceptable to be called end-to-end encryption.
Agreed, transport encryption is the term to use for this model which is a great model anyway.
You can use e2e if the data-at-rest (e.g., video) file(s) are also 100% encompassing the encrypted in both the camera and the remote server, as well as the mobile app and remote server.
From the client-side, this E2E means no raw data are exposed over network nor in remote storage and that keys are required to view the raw data at either endpoints.
In today's parlance, the undefined portion of E2E is whether the local storage is encrypted as well. Some will argue on this point. Future may (and should) tighten this E2E as well.
The end-to-end encryption part is clear IMO: it's between the hub and the app, both of which are trusted. This is different from an untrusted server decrypting the messages.
The point of end-to-end encryption to me is that I don't need to have a trusted intermediary (in this case the hub).
Anyway, either way it's probably good to include something about how the traffic between the camera and the hub is completely plaintext and unencrypted and includes the password to the camera (unless I'm missing something), so even in your model it's not just the hub that is an additional point that needs to be trusted, it's also the whole network that they are on. That's probably at least a router and might include many other devices, sometimes quite untrusted.
Since some cameras support adding TLS/HTTPS it would be good to add support for that by not hardcoding http for the onvif endpoints. I think FFMPEG supports rtsp over tls out of the box.
I have mentioned the unencrypted traffic between the camera and hub here: https://github.com/privastead/privastead/blob/main/HOW_TO.md (Step 4, second paragraph)
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...
I haven't designed Privastead for continuous recording/streaming. It's mainly to receive motion/event-triggered videos and occasional live streaming. The usage model is more like Ring cameras.
That didn't answer my question.
Sorry, which question did I miss?
The question of "What is the purpose of introducing the untrusted "server" component?". Looks like you've since replied to this, but it wasn't here or I didn't see it when I dropped the parent comment. The reply also doesn't compare alternatives such as direct use of an object store API. I've fielded a lot of user support questions about installation and would really hesitate to add that extra moving part if it's not strictly necessary.
Overall, we must be coming at this with quite different expectations of what a NVR should do. Not just this but also "when the app fetches a video, the server deletes the ciphertext (in order to be memory efficient)". Some installations of my NVR software are multi-user; I personally use it from multiple devices; etc. So the idea the whole pipeline exists just to transfer event videos to a single Android device results in a system that I would not find useful.
There certainly is space for different approaches. E.g. Frigate's approach is quite different than Moonfire NVR's but obviously is useful in a lot of ways to a lot of people. But my take is that Privastead's approach is going to be pretty niche, and the claim that other NVRs don't offer strong privacy assurance using "end-to-end" (on-prem server to client) encryption is untrue.
Also, I find it inaccurate to say it's mostly implemented in Rust which "provides higher security assurance for the hub". The Amcrest camera you've chosen is essentially developed by a hostile nation-state, and the protocol code you're using to interact with it (ffmpeg) is all written in C, which I find incongruous with the privacy/security goals. In fact, ffmpeg's RTSP and Matroska code is probably the majority of lines of code in the system.
Yes, we have different approaches/designs. In fact, I don't even of think of Privastead as an NVR solution. The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.
And my main comparison has been with security camera solutions that use their cloud solution to transfer videos (e.g., Ring). I think an open source solution that uses MLS and treats the cloud as fully untrusted is a superior alternative.
Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.
Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)
> The choice of using a hub is mainly because I didn't have control of the camera firmware. As I've mentioned in other comments, if I could, I'd move the hub logic to directly run inside the camera.
Yeah. I'm also frustrated with cameras in general. I've commented on this a few times here before, [1] but tl;dr: I don't even know what camera I'd recommend even if I had the perfect open source firmware to flash onto it easily.
> Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.
Okay, interesting, yeah that sounds like a significant step up for most folks.
> Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)
Patches very welcome. It could use more attention than I've been able to give it recently but likely will interact well with your camera model as-is.
[1] https://news.ycombinator.com/item?id=37815064
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.
So someone is going to access your camera, power it off, flash a custom firmware to it that they have themselves written that gives them backdoor access to the camera, somehow set it up so that it also has network access that you cannot see on your firewall or network monitoring tools? Then they login to your servers and hope that you don't have any logs enabled that automatically get sent off to a cloud server somewhere. Sounds like your friend has some three letter agency enemies.
secure boot does not solve such problem.
Don't leave me hanging there, you have to elaborate.
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”.
Curious, does your MP3 plays "Let the Bodies Hit The Floor" by Drowning Pool?
https://genius.com/Drowning-pool-bodies-lyrics
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.
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.
Hmm I don't trust Google at all to be honest. I don't even use a Google account on my android phone anymore.
I do have some ring cameras but they're only looking at my front door and I've cut the microphones out of them (they're incredibly sensitive, I could literally hear myself word for word two rooms away).
Most of my cams are TP-Link used in local mode with internet access blocked.
> And even if someone did manage infiltrate Google, they'd very likely target someone high-value before me
The risk isn't just an evil insider infiltrating Google.
It's also that a lot of home security companies are in the business of having a friendly relationship with the authorities. So if the cops were investigating a fender-bender down the street and they ask Google for your videos? Better hope that living room camera doesn't show anything you wouldn't want the cops to see, because it's getting handed over.
Yeah ring had a dirty habit of doing this too.
But they've stopped apparently: https://www.wired.com/story/ring-police-rfa-tool-shut-down/
Still, I've disabled the microphones in mine and they only see my front door anyway.
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.
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?
That's definitely better, if done right. I still prefer to avoid port forwarding on my router if possible. The fewer attack surfaces I have to worry about, the better.
No mention of Tailscale ? It's dead simple.
Right? All of this seems like trying to solve the wrong issue. Solve VPN routing with a routing solution, solve stream collection and processing with something like Frigate. I run ML models locally on a GPU and get a notification through MQTT/HA/Tailscale to my phone when the local stray cat arrives for dinner. What else do you really need?
I don't buy the cheap storage argument, trading an upfront cost of maybe $100 for all that complexity. And you can still keep archives - and even a reasonable UI - with some off the shelf FUSE driver. Or, less janky, a cron script running rclone or whatever.
Cool project, I just don't see people migrating to it.
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.
If you want to watch a talk from a person with good presentation skills on this point, I would recommend the following video: https://youtu.be/cWSh4ZxAr7E?t=3314
I can hep you scale it to handle many cameras without gpu
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.
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?
I have a bunch of Amcrest brand cams, indoor and outdoor, plus one Reolink combination floodlight/camera.
I like these PoE outdoor ones best: IP5M-T1179EW
Indoor PTZ ones: IP4M-1041W
Old wifi outdoor one: IP4M-1026E
I got some with the plastic dome around them but they do not work well at night, especially in weather.
I also have a ridiculous industrial PTZ camera that I put on my roof to watch birds, planes, and boats, and this thing is an absolute beast. I love it. https://www.alibaba.com/product-detail/4k-action-ptz-camera-...
Those Amcrest cameras are rebranded Dahua products with the logos changed. Right down to the firmware bugs and confusing UI. They’re actually great cameras for the money, but man do I loathe their quirks sometimes.
I use Reolink fwiw. Cheap china cameras which stream in https & rtsp in h264 and h265.
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
I can second Frigate and welcome any work in this space, so nice work OP will have a look. For others asking, I have found so far Hikvision POE PTZ domes like DS-2DE2A404IW-DE3 have been reliable, depends on your budget. I have cams themselves fully locked down from internet and on a separate subnet on the local net. OPNSense is also a friend here. I would love some OSS firmware for these cams. For remote, I find ZeroTier to Frigate & Home Assistant machines is all I need. I get why others WireGuard too. YMMV
Search for "Hikvision compromised" though. The results are damning. I suppose there's not much of a concern if using a proper firewall on a managed network, however.
Aren't HikVision the ones banned by many governments because they have dodgy "call home to China" firmware?
Persoanlly I go with the Eyeball Entities Omnicam with an Omniscient Systems Xcam-REAM control centre [0].
[0] https://cybershow.uk/media/ads/cctv-ads.mp3
Even if it does have phone-home functions, why does the camera itself need internet access?
IMO, audit the hardware for wireless radios (PoE cameras shouldn't have them), and put them on a camera-only VLAN that can only talk to the video server.
Maybe not suitable for super secure TS locations, but in general should be fine for 99% of situations.
I think if you've got total control over them, not a problem compartmentalising. Problem is, they're like loitering munitions, next person comes along and connectes them up to a router or misconfigures a firewall... Much as I hate e-waste sadly best place is in the bin. They're cheap but, easy come easy go.
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
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.
WebRTC might provide a good way to handle this.
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.
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?
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. :-)
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!
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).
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.
How is video streamed to the apps? Push notification services are not meant for real time video streaming.
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.
RTSP
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
Interesting. I think the usage model provided by Privastead is reliable enough (at least for me). I have access to my videos on my phone. If losing the phone is a concern (which should be rare), we can easily add a feature that keeps a copy of the files in the hub too.
> 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.
I suspect there’s a tendency by the kind of developers who make fancy open source projects to expose all the awesome nerdy power of their software. Have three different motion detectors? Expose all of them! Make them plugins! Have “extensions”! Have components provide “things!” Make a UI for all of that! It’s especially nifty when the UI looks just like the code structure.
But making a good UI for defining object detection zones is hard, so the very first thing that works at all sticks. Or, once you’ve carefully optimized by using the camera’s built in motion detection and having all the streams you could want, supporting software motion detection is an afterthought, and making it configurable in any useful manner is even more of an afterthought. After all, all the cameras you actually use personally have built in detection that works well and also have so many built-in RTSP streams that you never actually had to optimize for the experience of using a camera with a single stream, a somewhat defective implementation of ONVIF, and entirely unusable motion detection. So you make it work, but only using plugins and extensions, and it never becomes pleasant.
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.
Yeah my ring alarm worked well too when my place was broken into. It scared them off, they broke down the door but didn't actually come inside.
Unfortunately that prompted to police to be less than helpful (they considered it vandalism instead of a burglary and didn't even take prints). And because they didn't enter the house my cameras didn't see their faces so I couldn't try to track them down on my own either. But at least my stuff was ok.
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?
I think the hub thing is where the local storage is? I don't know if they are just open RTSP things or not that you could use with any random NVR?
I have unifi WiFi APs so have all the rest of the hub/controller anyway and trialled one camera but ultimately opted for Nest cameras instead.
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.
Unfortunate. Reolink even has wireless cameras, but they will require a DC input, so you'd need an outdoor electrical outlet if you can't drill any holes and sneak either a power or UTP Ethernet cable.
Given the strict physical requirements, you might be looking at battery-backed wireless cameras of the type often found on Amazon, but afaik they will never offer the local storage or control you want.
I will say that surprising things can be accomplished with small drilled holes and a fishtape. Your risk tolerance and how nice the rental are obviously very important factors.
I used a Reolink Argus with a battery and Wi-Fi connection. The one I used is probably EOL now, but a quick look at the site shows even solar chargeable options. So, it is possible.
I've got a Reolink Argus 2E which look like it's been replaced by the 3E, but it works great without any wired connection to the house. I've got it solar powered and strapped to a tree, unprotected by the elements. 2 years and still working.
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.
Autoupdate is on by default.
Even for local auth, the auth database comes from the cloud service.
Either way I wouldn't say it's "reasonable" that anyone at Ubiquiti has access to your NVR. A very skeptical and doomer take imo.
"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/
I did not, but I will. I would just point out that Privastead assumes the the push notification infrastructure is untrusted anyway.
Sure, just wanted to tell you about it, as this seems to be defacto standard for foss android apps, for example most if not all https://matrix.org clients use it for push notifications (when you use their de googled build, or don't have play services) available. I also use a Signal fork with UnifiedPush and have some server alert scripts which post to my self-hosted ntfy instance, and the ntfy app itself will display them (otherwise for the Messengers, the Notifications will be from the messenger app itself, as these apps get "notified" aboout a notification and then do their own thing).
it's not about trusted/untrusted as in what will they do with the data. it's entirely about will the service be available long term or if theGoogs will deprecate it in the future.
I have no skin in the game of push notification infrastructure, but we've seen plenty of ShowHNs where a critical part of the Show is a total dependency on a 3rd party shim. While this isn't something like a dependency on a Twitter API that suddenly got yanked, it is still something that devs should really consider. Especially given theGoogs' track record.
Maybe this isn't the case it is a library deeply embedded in the Android ecosystem, but anytime a ShowHN mentions a dependency on theGoog it sets of the SpideySenses