Our project specifically is only meant for Raspberry Pi Zero 2W. We decided on this early on due to Raspberry Pi being a safer source for hardware, and it allows much more customization (e.g. custom 3D printed cases, our HAT, etc). We also wanted it to be a WiFi camera that's super easy to setup and doesn't require technical knowledge to use.

Apple has not approved our documentation for 23 countries in Europe yet. They require it for the European Union Digital Services Act [see https://developer.apple.com/help/app-store-connect/manage-co...]. Note that the Android app is available in these (both in the Google Play Store as well as Obtainium).

France, specifically, is excluded due to needing a specific French encryption declaration form. [https://developer.apple.com/help/app-store-connect/manage-ap...] - as we do not have a lawyer to consult, we decided it would be best to hold off on this to be certain we do it right.

For some other specific countries outside of Europe, such as North Korea, we are required to abide by export laws in the US. We tend to try to go on the safe side when excluding, as we do not have a lawyer to consult.

Please let me know if you have any other questions!

In case you're not familiar with the Yocto Project, it's designed to be a tool/template for developers (like Ardalan and I!) to use to create custom Linux images for embedded devices (in this case, a Raspberry Pi).

It works off of distributing layers/recipes (these "templates") in open-source repositories for re-use among such developers that can be very easily baked in and customized if necessary.

Our current usage of it is relatively small. Our OS codebase is roughly ~1,000 LOC of a few recipe modifications (e.g. for fixing reproducible build issues, some minimizations, necessary dependencies we need), and, of course, integrating our camera_hub binary and updater binary (as well as their respective system services). We also bake in a custom rpicam-apps (the library responsible for driving camera feeds into the app), which was modified to be more performant in our use case (specifically, we modified it to add a secondary UNIX domain socket channel to send raw images simultaneously with the H.264 stream, so that we wouldn't need to decode them separately). Additionally, there's ONNX Runtime, which I mention below.

In the image itself, we've added two partitions: a data and provisioning partition. The data partition is designed to separate the mutable data (the state files for our camera binary) against the rest of the root filesystem. The provision partition is used by the deploy tool to inject a random camera_secret in as the pre-shared key (PSK) used to initiate pairing in OpenMLS (for our E2EE).

We have a lot of future work in store for this Secluso OS! A few things I'm working on right now are a read-only root filesystem (through squashfs), hardening the kernel, and getting rid of a massive dependency we currently rely on (ONNX Runtime) for machine learning. We've been working with burn, a popular Rust machine learning library, to optimize their "burn-flex" crate to match the performance of ONNX Runtime for the model we use for object detection. After that's done, half of the dependencies used by the OS will be able to be removed! (as ONNX Runtime drags in things such as python).

Please let me know if you have any questions!