[HN Gopher] Show HN: Open-source private home security camera sy...
___________________________________________________________________
Show HN: Open-source private home security camera system (end-to-
end encryption)
I needed a security camera inside my house, one that would send
motion notifications to my smartphone and would allow me to
livestream remotely. However, I could not find one that I could
trust due to privacy concerns. Many of them upload the plaintext of
videos to their servers and none is fully open-source as far as I
know. Therefore, I decided to use my spare time to build one from
scratch. Called Privastead (as in Private Homestead), it uses
OpenMLS for end-to-end encryption (between the camera local hub and
the smartphone) and is mostly implemented in Rust (except for part
of the Android app that is implemented in Kotlin). The system is
functional now and I've been using it in my own house for the past
couple of weeks. Based on some of the discussions I've seen
online, it seems like there are other users who are also concerned
with the privacy implications of home security cameras. Therefore,
I decided to open source my solution for everyone to use. If you
need a privacy-preserving home security camera, please give it a
try and provide feedback. Note that trying out the system requires
you to have a supported IP camera, a local machine connected to the
IP camera, a server, and an Android smartphone. I have put together
detailed instructions on setting up the system, which I hope makes
it easier for others to get the system up and running. In
addition, consider contributing to the project. The prototype
currently has a lot of limitations: mainly that it has only been
tested with one IP camera, only allows the use of one camera, and
only supports Android. I'll continue to improve the prototype as
time permits, but progress will be much faster if there are other
contributors as well.
Author : arrdalan
Score : 443 points
Date : 2024-11-30 22:13 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| KetoManx64 wrote:
| 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.
| ranger_danger wrote:
| The best time to have security cameras is yesterday. Same for a
| dash cam. Please protect yourself and your loved ones.
| arrdalan wrote:
| 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/
| chgs wrote:
| You should do a ShowHN on it!
| LoganDark wrote:
| 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.
| yieldcrv wrote:
| 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
| krisoft wrote:
| > 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.
| yieldcrv wrote:
| 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
| ndsipa_pomu wrote:
| 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.
| arrdalan wrote:
| 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.
| EthicalSimilar wrote:
| 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
| amluto wrote:
| > 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.
| corytheboyd wrote:
| > 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.
| amluto wrote:
| 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.
| arrdalan wrote:
| 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.
| cvwright wrote:
| 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
| nzeid wrote:
| 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.
| arrdalan wrote:
| 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.
| hathawsh wrote:
| 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?
| arrdalan wrote:
| 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.
| euroderf wrote:
| No mention of Tailscale ? It's dead simple.
| pzduniak wrote:
| 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.
| globalnode wrote:
| 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
| :)
| arrdalan wrote:
| 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.
| gauge_field wrote:
| 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.
| globalnode wrote:
| 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.
| scotty79 wrote:
| 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.
| arrdalan wrote:
| 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.
| hereme888 wrote:
| Dude good job. Thanks for this.
| VTimofeenko wrote:
| 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.
| stevenpetryk wrote:
| 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.
| hughesjj wrote:
| 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
| hunter2_ wrote:
| 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.
| hipitihop wrote:
| 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
| nonrandomstring wrote:
| 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
| paranoidrobot wrote:
| 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.
| nonrandomstring wrote:
| 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.
| VTimofeenko wrote:
| 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.
| arrdalan wrote:
| 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. :-)
| VTimofeenko wrote:
| 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
| arrdalan wrote:
| 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.
| tehlike wrote:
| WebRTC might provide a good way to handle this.
| arrdalan wrote:
| 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.
| windexh8er wrote:
| 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?
| arrdalan wrote:
| 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. :-)
| hamandcheese wrote:
| 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).
| arrdalan wrote:
| 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.
| goodpoint wrote:
| How is video streamed to the apps? Push notification services
| are not meant for real time video streaming.
| discordance wrote:
| RTSP
| arrdalan wrote:
| 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.
| dylan604 wrote:
| "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?
| arrdalan wrote:
| 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.
| SushiHippie wrote:
| The open source/degoogled alternative to that is UnifiedPush,
| did you take a look at this?
|
| https://unifiedpush.org/
|
| https://ntfy.sh/
| arrdalan wrote:
| I did not, but I will. I would just point out that
| Privastead assumes the the push notification infrastructure
| is untrusted anyway.
| dylan604 wrote:
| 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
| SushiHippie wrote:
| 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).
| StayTrue wrote:
| 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/
| arrdalan wrote:
| 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.
| bobbob1921 wrote:
| 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
| amluto wrote:
| Nifty. Have you considered trying to make the server be able to
| run as something like a Cloudflare worker?
| arrdalan wrote:
| 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.
| amluto wrote:
| 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.
| hackermeows wrote:
| Do self hosted options qualify for insurance discounts ?
| arrdalan wrote:
| 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.
| h317 wrote:
| 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=...
| hedora wrote:
| 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.
| modeless wrote:
| 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?
| mattlondon wrote:
| Ubiquiti cameras store the data on-prem.
|
| Not open source, and not the cheapest (but not absurd either).
| App is acceptable.
| Tempest1981 wrote:
| I read elsewhere that people are upset since Ubiquiti now
| requires using Unifi hub, at least for initial configuration.
| Maybe others do too?
| mattlondon wrote:
| 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.
| 9dev wrote:
| 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?
| modeless wrote:
| 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.
| wkat4242 wrote:
| 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.
| wkat4242 wrote:
| 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.
| modeless wrote:
| 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.
| 9x39 wrote:
| 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.
| modeless wrote:
| 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.
| 9x39 wrote:
| 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.
| kdmtctl wrote:
| 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.
| ryandrake wrote:
| 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.
| mattlondon wrote:
| 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.
| wkat4242 wrote:
| 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.
| mattlondon wrote:
| 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.
| michaelt wrote:
| _> 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.
| wkat4242 wrote:
| 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.
| wkat4242 wrote:
| 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.
| arrdalan wrote:
| 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.
| xyst wrote:
| > 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".
| stevenicr wrote:
| 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'
| bobbob1921 wrote:
| 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.
| INTPenis wrote:
| 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.
| goodpoint wrote:
| What's a realistic use-case for secure boot on a camera? It's
| such a corner case...
| stragies wrote:
| 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.
| INTPenis wrote:
| 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.
| moritonal wrote:
| There is also https://shinobi.video/, as another alternative.
| eth0up wrote:
| 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/
| genericacct wrote:
| 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
| ww520 wrote:
| 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.
| arrdalan wrote:
| This is a reasonable setup. We discussed it in other comments
| as well
| unit149 wrote:
| >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.
| kkfx wrote:
| ZoneMinder?
| gregoriol wrote:
| Using it!
| 0points wrote:
| 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.
| acidburnNSA wrote:
| 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.
| thelittleone wrote:
| I'm looking at a similar setup. Mind sharing which cameras
| you went with?
| 0points wrote:
| I use Reolink fwiw. Cheap china cameras which stream in
| https & rtsp in h264 and h265.
| acidburnNSA wrote:
| 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-...
| smitelli wrote:
| 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.
| arrdalan wrote:
| 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.
| nubinetwork wrote:
| 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?
| arrdalan wrote:
| 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.
| jokowueu wrote:
| Fantastic , thanks
| SahAssar wrote:
| 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).
| arrdalan wrote:
| The traffic is encrypted between the hub and the app. The
| camera is connected to the hub.
| SahAssar wrote:
| 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.
| arrdalan wrote:
| 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.
| SahAssar wrote:
| 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.
| vineyardmike wrote:
| 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.
| EGreg wrote:
| 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
| tills13 wrote:
| 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.
| tuchsen wrote:
| 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 :).
| sneak wrote:
| 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.
| prymitive wrote:
| 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.
| squarefoot wrote:
| 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.
| scottlamb wrote:
| 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
| sneak wrote:
| I assume it's to leverage a) cheap/scalable cloud storage and
| b) offsite storage for security/ease of access.
| scottlamb wrote:
| 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...
| arrdalan wrote:
| 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.
| scottlamb wrote:
| That didn't answer my question.
| arrdalan wrote:
| Sorry, which question did I miss?
| arrdalan wrote:
| 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.
| arrdalan wrote:
| 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.
| coppsilgold wrote:
| 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 and RSA-KEM together to provide post quantum resistance.
|
| The traditional symmetric approach (which also has post quantum
| resistance) in such systems requires the 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...>
___________________________________________________________________
(page generated 2024-12-01 23:00 UTC)