What wasn't immediately clear to me is that you're meant to set up Raspberry Pis with a Pi camera attached, and that serves as the camera device. This then provides E2E encryption directly between the Pi and the Secluso mobile app via a cloud relay service that just shovels the encrypted bytes.
Contrast with https://frigate.video/, which is a locally installed NVR server that pulls camera feeds over the LAN (from a very wide range of off-the-shelf IP cameras) and does all kinds of really neat local processing to do things like (optionally hardware-accelerated) object and audio detection, face recognition, ALPR, semantic search over recorded video, and more — while still maintaining similar privacy guarantees.
It's great that you've done reproducible builds for camera firmware, since that means you don't have to trust a shady IP camera vendor to be competent. Of course, with off-the-shelf stuff, you can largely avoid the security issues there by putting your cameras on a VLAN that can only reach your NVR.
What I don't get is why there needs to be a cloud relay involved at all. If you're fully E2E encrypted anyway, just have the app communicate directly with the camera via STUN.
I see you're planning on selling the preassembled hardware. There's definitely something to be said for "buy this device, download app, done" ease of setup for the wider market that meaningfully improves their privacy over Ring/Nest/et al. But for the power user and self-hosting crowd, I think Frigate makes a lot more sense.
There are two comments/questions here and I'll try to address them one by one.
Secluso vs. Frigate: I think you correctly mentioned some of the differences. We intend Secluso to be replacement for Ring-like WiFi cameras. Therefore, it needs to be easy to set up and use and provide similar functions to a Ring camera: the user plugs in the camera, opens the app, scan a QR code and perform a pairing process, and the camera is ready to use with its strong end-to-end encryption. The self-hosted version of Secluso requires a few more steps, but we've tried to automate it as much as possible. Home Assistant and Frigate are great platforms that are capable of providing good privacy (although they don't support advanced end-to-end encryption that Secluso does with forward secrecy and post-compromise security through MLS), but they require several steps, e.g., prepare/configure the IP camera, install and configure Frigate, integrate Frigate with Home Assistant, and configure remote viewing via cloud relay or VPN. Also, they are typically used with wired (Ethernet) IP cameras. WiFi IP cameras are possible but the RTSP stream between the camera and hub will be unencrypted, which might be vulnerable to eavesdropping.
Need for cloud relay: We have considered STUN and we are planning to deploy MLS over WebRTC for livestreaming (using the DAVE protocol) to improve the livestream performance. But this doesn't completely eliminate the need for a relay. If a STUN connection cannot be made due to some restrictions in one of the networks (that the camera and app are connected to), we will need to fall back to the relay. Also, if the phone is off/disconnected when an event video is recorded, we would like to transfer it (encrypted) to the relay ASAP in case something happens to the camera (e.g., it's taken by the intruder).
> the company prevent you from working in any open source work, including personal ones without a written permission, and everything you do will be the company property on or off duty
PSA: If you're in California, these kinds of employment contract terms are (mostly) illegal and unenforceable.
Labor Code 2870 outright invalidates any employment contract provision which attempts to claim ownership of IP rights to anything “that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information” unless it relates to the employer's business or results from other work performed for the employer.
Labor Code 96(k) prohibits employers for disciplining or firing an employee who engages in “lawful conduct occurring during nonworking hours away from the employer’s premises,” with an exception for contracts that prohibit conduct by the employee that is in direct conflict with the employer’s “essential enterprise-related interests.”
So blanket prohibitions are out. If you're doing something that closely relates to your employer's products/business or could be construed as a conflict of interest, that's when you should consider written permission, but a company can't say “no” unless it actually relates to the company's business.
California is relatively unique in these worker protections, and they're a big reason why Silicon Valley became what it is.
It has been a long time since I've done this, but:
If your Android is rooted, it's pretty easy to get tethering working. There's magisk modules that can fix the TTL problem and/or disable the hidden carrier-installed software that Android will ask for permission before enabling tethering.
> Tvheadend is the leading TV streaming server and recorder for Linux supporting ATSC, DVB-C/C2, DVB-S/S2, DVB-T/T2, ISDB-T, IPTV, SAT>IP and HDHomeRun input sources. Tvheadend outputs HTTP (VLC, MPlayer), HTSP (Kodi, Movian) and SAT>IP streams, and can ingest multiple Electronic Program Guide (EPG) formats including over-the-air (OTA) broadcast data for DVB and ATSC, and OpenTV extensions like XMLTV and PyXML.
So it's a DVR project in the vein of TiVo and Windows Media Center.
Oh, I must be misremembering. I also used to use it with XBMC/Kodi, but I recalled kodi itself being the dvr element. Or maybe I’m even conflating it with plex. It has been a minute :D
Having read that thread, I guess one of the small upsides of the world I live in is that "FIFA Peace Prize" is now available as a joke award reference. FIFA really hit it out of the park there in a way that even their normal legendary levels of corruption couldn't imagine.
Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
> Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
For future reference, you can use: "knocked it into the top corner", "put it in the back of the net" or "smashed it past the keeper". Not a native football-talker, but hang out too much with a few.
"Back of the net" doesn't feel the same to me even though (I learn after reading far too much about a sport I do not play) "Out of the park" is basically the same thing.
In my mind "out of the park" had meant the ball leaves the actual stadium but in fact (I read) "the park" in this context is actually the field of play and so "out of the park" represents in fact the vast majority of home runs and not the over-achievement I had imagined.
True, "back of the net" is more "someone kicked the ball really hard and it hit the back of the net really hard" instead of "the ball came across the goal line" which can be very different, so in my mind that's as close to "out of the park" as you can get in soccer :)
There's no reason you have to run ESPHome on your Home Assistant server.
It's offered as a HA a̵d̵d̵o̵n̵ app for ease of use (makes it a one-click install), but you can also just `pip install esphome` or use the provided Docker image and get the exact same UI, but with everything (including compilation) running on your much beefier laptop.
So your binaries get compiled quickly and you can still do the OTAs directly from your laptop. HA needn't be involved.
> You can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?
This is how I did it, instead of the container or HA OS in a VM.
If you want the simplicity of everything preconfigured, managed, and hands-off, go with HA OS, whether in a VM on a beefier machine, standalone, or the HA Green/Yellow dedicated hardware.
But if you already have a home server and want to add HA, I found just pip installing to be easier than dealing with the container.
Maybe I'm just the silly type that enjoys fiddling with Linux, but I'd argue that it actually makes more sense to install HA bare metal over a container. HA doesn't actually have any major dependencies outside of what pip installs, so setup wasn't any more annoying than via container. And then you never have to deal with container annoyances like passing hardware through to it or weird failures and misconfigurations.
Contrast this with https://frigate.video/, which has so many fragile native dependencies and a super complex stack that trying to install manually is an exercise in futility. I gave up and used the container.
The much more likely culprit is your VPN server's port. If it's running on some no-name port (such as the default 51820), that's likely to get throttled.
I'd bet that switching your VPN server port to 443 would solve the problem, since HTTP/3 runs on 443/udp.
This is a clever reuse of WireGuard's cryptographic design, and may indeed make sense as a way to slap some low-overhead encryption on top of your app's existing UDP packets.
However, it's definitely not a replacement for TCP in the way the article implies. WireGuard-the-VPN works because the TCP inside of it handles retransmission and flow control. Going raw WireGuard means that's now entirely up to you.
So this might be a good choice if you're doing something realtime where a small number of dropped packets don't particularly matter (such as the sensor updates the article illustrates).
But if you still need all your packets in order, this is probably a bad idea. Instead, I'd consider using QUIC (HTTP/3's UDP protocol), which brings many of the benefits here (including migration of connections across source IP address and no head-of-line-blocking between streams multiplexed inside the connection) without sacrificing TCP's reliability guarantees. And as the protocol powering 75% of web browsing¹, is a pretty safe choice of transport.
> However, it's definitely not a replacement for TCP in the way the article implies.
UDP isn’t TCP and that’s kind of the point. For a large number of use cases the pain TLS imparts isn’t worth it.
QUIC is flexible and fabulous, but heavyweight and not fit for light hardware. it also begs the question “If the browser supported raw UDP what percent of traffic would use it?”
Sure, but this article spends paragraphs talking about the (real) problems with TCP, then suggests that the solution is a UDP-based transport with WireGuard-ish crypto.
…but there's a giant guaranteed-and-ordered-delivery-sized hole in that argument, which is my point. The article never addresses what you lose when going from TCP to UDP. You can't just swap out your app's TCP-based comms with this and call it a day; you're now entirely responsible for dealing with packet loss, order, and congestion if that's important to your application. Why DIY all that if you could just use QUIC?
Granted I haven't personally tried to run QUIC on embedded hardware, so I can't speak to its weight, but I do see someone did it¹ on an ESP32 (ngtcp2 + wolfSSL), so it can be done with < 300 kB of RAM.
I wonder how much RAM this WireGuard-based approach requires. The implementation here is in .NET, so not exactly appropriate for light hardware either.
Regarding browser support for UDP, you'll never get raw UDP for obvious reasons, but the WebTransport API² gives you lowish-level access to UDP-style (unreliable and unordered) datagrams with server connections, and I believe WebRTC can give you those semantics with peers.
This is an… interesting choice for archival purposes. What exactly do you think makes HFS+'s reliability better? The only thing I can think of is that HFS+ has journaling while FAT and derivatives do not, but that doesn't particularly matter after the data is on the disk and it's cleanly unmounted (which should be a safe assumption in most archival scenarios).
The Linux HFS+ driver is basically unmaintained, and cannot write to journaled disks. On Windows, the only choice a paid driver. I guess it's fine if you're strictly a Mac user, but it's a real problem if you need to access the disk on another machine. Even if you don't, I still wouldn't trust Apple for long-term support of anything.
Meanwhile exFAT has native support on Windows, Mac, and Linux, and there are drivers for BSDs and others.
So 20 years down the line, you'll certainly have something that can read an exFAT drive without much if any pain, regardless of which platform you're using at the time. HFS+? Who knows.
That said, I'd consider ZFS or btrfs for HDD archival. Granted broad (Mac/Windows) support is weaker than FAT, but at least the filesystems are completely open source. But what really makes them interesting is their automatic data checksumming to detect (and possibly repair) bitrot, which is particularly useful for archival.
> This is an… interesting choice for archival purposes. What exactly do you think makes HFS+'s reliability better? The only thing I can think of is that HFS+ has journaling while FAT and derivatives do not, but that doesn't particularly matter after the data is on the disk and it's cleanly unmounted (which should be a safe assumption in most archival scenarios).
Yes, journaling. Power cuts or unclean unmounts are enough of a risk for me that I don't see any reason to use a file system without journaling.
> The Linux HFS+ driver is basically unmaintained, and cannot write to journaled disks. On Windows, the only choice a paid driver. I guess it's fine if you're strictly a Mac user, but it's a real problem if you need to access the disk on another machine. Even if you don't, I still wouldn't trust Apple for long-term support of anything.
I just don't expect Linux or Windows support to be relevant to me or my family's use, or the cost of the Windows driver to be a problem if it ever came up.
If in a decade Apple drops HFS+, it's not something they're going to do without notice, it's something where I'll have plenty of notice to take the relatively small required effort to migrate my archives to a different file system.
> That said, I'd consider ZFS or btrfs for HDD archival. Granted broad (Mac/Windows) support is weaker than FAT, but at least the filesystems are completely open source. But what really makes them interesting is their automatic data checksumming to detect (and possibly repair) bitrot, which is particularly useful for archival.
I use btrfs for non-archival storage, but don't really see it as useful for archival storage - it's effectively unusable for my wife if I get hit by a bus.
> So 20 years down the line, you'll certainly have something that can read an exFAT drive without much if any pain, regardless of which platform you're using at the time. HFS+? Who knows.
You're optimizing for a problem that isn't in my risk assessment - i.e. I don't care if can shelf a drive and easily read from it in 20 years, I just want to maximize reliability over a 20 year timespan where I'm willing to take maintenance action if required. (And I think you're overly negative on Apple's support of old tech. e.g. Apple's didn't drop software Firewire support for a decade after they stopped selling their last Firewire device - that's plenty of time for a migration if my archival drives were using a Firewire connection. HFS+ is Apple's currently-supported file system for non-SSD storage, and I don't see a medium-term path where they extend APFS support to HDDs or drop HDD support entirely.)
Contrast with https://frigate.video/, which is a locally installed NVR server that pulls camera feeds over the LAN (from a very wide range of off-the-shelf IP cameras) and does all kinds of really neat local processing to do things like (optionally hardware-accelerated) object and audio detection, face recognition, ALPR, semantic search over recorded video, and more — while still maintaining similar privacy guarantees.
It's great that you've done reproducible builds for camera firmware, since that means you don't have to trust a shady IP camera vendor to be competent. Of course, with off-the-shelf stuff, you can largely avoid the security issues there by putting your cameras on a VLAN that can only reach your NVR.
What I don't get is why there needs to be a cloud relay involved at all. If you're fully E2E encrypted anyway, just have the app communicate directly with the camera via STUN.
I see you're planning on selling the preassembled hardware. There's definitely something to be said for "buy this device, download app, done" ease of setup for the wider market that meaningfully improves their privacy over Ring/Nest/et al. But for the power user and self-hosting crowd, I think Frigate makes a lot more sense.
reply