This sounds basically like a STUN/TURN + P2P solution which in itself _does not_ mean it's unsafe! It can be unsafe just as anything else out there if it's made unsafe.

As explained by the company representative (including my own added explanations) the devices, when behind NAT, can not receive any incoming requests without setting up port forwarding in the router (this is done automatically and temporarily for outgoing requests to allow incoming respones, but thats another story). Setting up port forwarding is not a good solution so what I pressume they are doing is that they are connecting to a TURN/STUN server from the camera outwards to be able to communicate. When the application wants to connect that one also connects to this server to have the camera create a p2p link (that means direct connection between camera and the device the app is running on). If that one fails then they are relaying the data through their servers.

Now there's some ceveats for the above solution. If one relies solely on encrypted channels and certificate security it should be as safe as the encryption is strong or the strength of the certificates. If not done properly, say client/peer verification is missing or the encryption chain isn't complete, then it's most likely bad. However:

The single most important thing is that the _functionality itself_ and the technique used is not unsafe per se.

The author makes it sound like it's a giant P2P-pool of camera devices, however this does not seem to be the case. Rather it seems to be a big network of relay servers to reduce latency for the connected devices. Big big difference there.

(Then one may question the inability to turn it off or that its enabled by default, but thats another question)