Yes, we are working on such a video. I will follow up here once that is ready.

https://mozilla.github.io/cargo-vet/index.html

2.4 “Importing Audits” goes into these third party auditors (the registry).

I can’t speak to the account thing, I checked the guy you replied to and it seems like his is 3 months old, not yesterday.

I wanted to mention that we plan to get a third-party security audit by a reputable firm sometime this summer.

Thingino looks like a great option for changing firmware of IP cameras to be open-source, and is useful in local NVR-like setups! Our goal is to different: provide an end-to-end encrypted, easy-to-configure and easy-to-use WiFi camera.

To help mitigate that, we use Cargo.lock files to pin all of our dependencies checksums (integrity validation) until we want to upgrade. When we upgrade, we’re working on having Cargo Vet to manually go through (in addition to trusted third party auditors) to ensure the changed code isn’t malicious.

We’ve only tested with a few cameras, and it’s able to support that well.

We have work in progress for users. We use OpenMLS for end-to-end encryption and it allows for creating groups. We’re using that to allow multiple apps/devices to receive encrypted videos from the camera. We have the core function implemented, but haven’t added UI support in the app for it yet.

In theory, that should be possible. We haven’t tested it.

We like the Pi because:

• It has a hardware-accelerated H.264 encoder (Broadcom VideoCore IV GPU). This allows video encoding to be off-loaded off the CPU.
• The extra compute allows us to do be able to do higher frame-rates and video quality than an ESP32 is capable of
• We made our motion detection for events more accurate through offering the option of human/pet/vehicle detection, which I don’t think ESP32 would be capable of (at least not in terms of the level of accuracy we currently achieve).
• I haven’t researched this, but I’m not sure if an ESP32 could handle the end-to-end encryption computation, unless it has a co-processor for it

Thanks for your interest!

We tried adding it on f-droid, but it seems like they have a backlog of projects to add. They haven’t gotten to test it out yet it seems.

This is why we now support Obtainium for people that do not wish to use Google Play. It can be hooked up to our mobile_client repository releases to pull the universal APK.

We do not charge anything for DIY. For our future offering, we have some information on the main page (secluso.com) of our site in section 4, along with what you would get.

Sorry about that! Is there anything specific I can answer?

The base runs on a Raspberry Pi Zero 2W. This is capable of running motion and AI detection (human/pet/vehicle). It supports live-streaming and motion/ai-detected events, which sends a 20 second video clip to the mobile app. All of this is end to end encrypted.

With DIY, you’re able to pick between an OV5647 and IMX219 sensor (Raspberry Pi Camera Module V1 and V2 respectively). With V1, it’s 1296x972. With V2, it’s 1640x1232 (97.4% of 1080p).

Hi kibblebits, please see below!

• We do not have telemetry.
• Our Android app is fully byte-for-byte reproducible. If you build it locally on your machine using our reproducible build script, it will match byte-for-byte the one in our GitHub releases. You can read more about reproducible builds here. In addition to our Android app, our deploy tools, OS image and binaries have these as well. This guarantees they were built from the source from our repositories.
• Our relay is self hostable on any VPS you like.

We’d be happy to add an option to disable auto update in our next release.

If you have any other ideas for features we can add or changes we should make, please let us know.

Thanks for the reply! Based on what I know about motionEyeOS, I would say the projects have different goals.

From MotionEyeOS’s website: “Get instant email notifications when motion is detected.”, “Save recordings to cloud services, network drives, or local storage. Automatic backup and archiving options.”

We differ because we specifically made this to not compromise on functionality. We offer push notifications, easy private access via our mobile app, and the cloud relay cannot decrypt videos.(whereas it seems if you were to use the cloud with MotionEyeOS, they would not be encrypted).

While you could go local in MotionEyeOS to avoid that, it would be more inconvenient for most people, and we wanted something that could be a non-feature-compromising private replacement to modern cameras that’s simple to setup and easy to use.

Bloef

Hi Bloef, this is meant to be a drop-in replacement to WiFi cameras (and therefore easy to use and easy to setup). A local NVR is great, and we definitely recommend it if you have the time to get one up and running.

Fair points. I appreciate the constructive criticism! Moving forward, we will improve on our documentation. In terms of review, we always review and test each other’s code (sometimes via other mode of communication), even if there weren’t any comments on the pull request.

Hi Brkdncr, thanks for the question!

We honestly do not have a concrete answer for the temp ranges. We’ve done some testing and made sure they stay under 150F in the 3D case shown in the picture.

We do not currently directly support solar/battery usage. You can probably DIY something together though!

For Software: We’ve started to thoroughly go through our dependencies by using the Cargo Vet tool, in addition to looking for unmaintained dependencies, dependencies that we can replace with a few lines of code, etc.

For Hardware: We’re using trusted hardware providers like Raspberry Pi to try to mitigate this.

Let me know if you have any other questions!

Those 11 commits were from a rebase-and-merge PR, which changes the date from the original commit. Notice how there’s a week gap between those and the prior commits on the main branch.

The only thing AI is used on in this project is strictly for user interface work (our website, the front-end for the mobile app, the front-end for the deploy tool). We carefully vet anything like that.

Hi kibblebits,

I pulled the links from the cloud camera controversies page from our website. We already had them compiled there. I didn’t pre-write any answers. And you can see from our GitHub history that we’ve been around for over a year and a half, and that we’re real people. Not bots.

Our automatic updates rely on immutable releases, ensuring that we can’t pull them back to try to hide something malicious. Additionally, we have reproducible builds, proving that the binaries / deploy tool / OS were derived from our codebase.

Everything is self-host able, you do not need to pay us to get anything working. Our plug and play camera is completely optional, we’re using it to help support our open source efforts and provide something that benefits the community.

Common commercial cameras such as Ring/Blink/Nest are privacy-invasive and have lots of controversies, some examples being…

• Ring provided employees with unfettered access to customer footage
• ADT technician spies on customers for 4.5 years
• Eufy lied about local-only storage
• Amazon has provided Ring doorbell footage to law enforcement 11 times in 2022 without the user’s permission
• Ring Super Bowl ad normalizes a civilian surveillance network

We started on this project a long time ago to fix these issues by making it so that no cloud provider can see your home security videos. It’s completely end to end encrypted and private-by-default. It also is super easy to use and doesn’t compromise on features. As it’s a Raspberry Pi and it’s open source, it’s completely auditable and not a black box (unlike these common camera providers).That means you can verify that nothing bad is going on within your camera, instead of relying on a promise from someone.