[arrdalan]

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]

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.

[egberts1]

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.

[arrdalan]

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.

[SahAssar]

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.

[arrdalan]

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)