There are new posts here indicating that the camera still connects to IPs outside the US. Previously, when this issue was first addressed on Reddit, they indicated that ALL connections will be within the US and they “pretended” to deliver that promise, but then we see posts like this (Wyze Cam V2 attempting UDP 10001 connections to Chinese IP - #7). Of course, they will have some new excuse, like “oh, it’s just for registration, we will fix it.” But they will never provide you with solid evidence that this is the case. They will assume that we will just take what they say for granted. In other occasions they reason the lack of providing evidence to the fact that only a “fraction” of people will understand the details behind the issue under concern. But it appears that they have no respect to the “fraction” of people that understands and care about these issues. They never released any solid evidence about their claims. They failed us.
Hi, the configuration is a manual process which needs collaboration between Wyze and our provider. It is more complicated than an on/off setting. We are checking with our provider based on the request. It will take a few days to collect all the device info. Thanks!
This is news to me. What is being held in China? While the USA is not as good as Europe in requiring strict security on personal data China is worse. Based on your response I may need to rethink using the products. You should also clearly state when purchasing and during setup what is being held where.
As you probably know we used ThroughTek as our P2P service provider. They are based at Taiwan and provide service globally. Their system was originally designed to serve devices globally with servers all over the world. This means when you make a connection, one server, which could be in different country, will help your phone find the specific camera. Once the phone finds the camera your phone will talk to the camera directly without the server. Nothing is ‘held’ on the server.
However there are customers who felt it is not enough. Last year we had a request to TUTK to limit network traffic with North America. TUTK implemented a mechanism to limit connection device traffic in specific region (e.g. North America or Europe). The implementation can be understood as assigning groups of devices under a specific region. We verified many times in our office that the device traffic is within North America. For the customer’s case likely one device group got mis-communicated for the region assignment. We are checking on it. We are also checking with TUTK to make sure all devices are configured under North America.
As a note: when device boot up, there is one registration which connects to TUTK servers worldwide. This can’t be changed in TUTK API unless we switch to a new set of API (which we plan to take a few months to integrate/deploy). Current we mitigate this by our firmware blocking known IPs that are non-US TUTK servers.
Thank you for the detailed information. Would you please delve a little deeper on how traffic flows for the request to view once the camera is configured in the system/server? For example does the request from the phone app have a local IP configuration loaded after configuration to direct viewing of the camera directly to the USA server and that server has no share outside the USA once the camera is configured on the server? Or does the request get routed to a master off shore which then redirects to the USA server/drive? Are videos stored only in the USA data center? As data security is something being called out everywhere today denoting adherence to high standards and describing (in layman’s terms) how Wyze implements for personal security is good marketing material. I ran several systems security groups in my career and instilled the motto Just because your paranoid doesn’t mean someone’s not out to get you :-).
Would you be willing to pencil out a quick diagram illustrating the “handshaking” etc you are describing here, snap a pic with your phone, and upload to a comment?
I’ve been asking for this for a long time without any luck and I don’t have enough knowledge about the subject to do it myself.
Would it best be expressed with more than one frame to illustrate authentication “steps” etc?
I’m using terms very loosely here, as reflects my shakey understanding. :-\
Happy to once Waze Tao reply’s or Wyze Tao can so we get the actual traffic pattern at an architectural level. I don’t expect Wyze to share any secrets.
Thanks, Irish.
This is all toward more effective connectivity troubleshooting for the customer. I contend that the more solidly informed you are about the fundamentals the better chance you have of self-helping.
FYI, I don’t really WANT to talk to tech support; nice as they are, I’m not lonely. If I get stumped after exhaustive self-help, THEN I need some tea and sympathy along with a magic bullet:
My friend, I feel your pain, here’s a potential non-intuitive solution.
I love you, Wyze wizard, as we speak I am ordering more product to gift my circle of friends and associates!
If I have a diagram and someone starts talking tech code, I can follow along better if I can “place” the component they’re speaking about on a diagram, then see the relationship of it to other components and the structure as a whole. I’m sure this is obvious and I’m not trying to school you, just to make explicit to Wyze why I’ve been advocating for MORE GRAPHICS in their support materials.
It’s much akin to having a world map app open on half your PC screen while reading a difficult piece about foreign policy on the other. Find the location, zoom-in, zoom-out… pan, spin, overlay… Ohhhhhh, interesting! I’m ready for the next gnarly nugget. 
Is it perceived as a security risk to be too visually explicit in public about this kind of stuff?
From my point of view, it’s all PFM. Speaking about my personal security (or maybe, privacy?) there seems little to be worried about. If bad guys want to “peep” into my home it seems harmless enough: It’s peeping into my home AND knowing where the home is, AND knowing who is or isn’t present, AND…
Tempest in a teapot.
Below is the logic between device and TUTK servers for illustrative purpose. I intentionally use generic words to hide detail implementation.
- During device setup time, the device registers itself with TUTK server to let Server know where it is. This is needed for TUTK to connect phone and the device in the future. However TUTK doesn’t know anything about Wyze user name, MAC, etc. We intentionally protected that.
- During device boot time, it registers itself with TUTK servers. Wyze’s code used IP filtering to block traffic to known oversea TUTK servers. We can only do that because TUTK API can’t do the filter inside their module.
- After device boots up, it will keep heartbeat with TUTK servers. TUTK provides a way (semi manual method) to keep heartbeat traffic to North American servers only. If you see heartbeat traffic out of North America. we would like to know the MAC address to check with TUTK on this.
- When a phone tries to connect to a device, the phone asks a TUTK server, which locates in North America by configuration, to find the device. The TUTK server will work on establishing a connection between the phone and the device. After that, the phone and camera will just communicate between them directly, without TUTK involved.
- For each camera connection, TUTK establishes a data channel (just channel, not data) between phone and camera. This is step 1/3. After that Wyze will take over to authenticate the phone to the camera. This is step 2/3. The last step is to send encrypted video data (AES 128-bit encryption) between phone and camera. This is step 3/3. The mechanism prevent TUTK from access Wyze camera stream directly.
The Wyze authentication is based on your user token generated from Wyze cloud. Please protect your user name and password carefully to avoid being hacked.
There is manual configuration step to get Wyze devices to be on North American servers. If there is traffic outside North America, likely there is a mis-configuration somewhere for old devices (we implemented the mechanism mid 2018). New devices should be more automatic now.
Regarding camera event videos, TUTK is not involved at all. Our cameras uploads event videos to Wyze account S3 storage via HTTPS connection. Phone downloads event videos from Wyze Cloud via HTTPS as well. This is also within North America.
Would it be reasonable to add a connectivity diagnostics utility to the app (that would offer to kick in after the Xth failure) graphically depicting the checks it was making as it was making them (highlighting flow success/failure) ultimately making a plain english recommendation for remediation and offering to automatically execute the courses of action where that would be possible (reboot cam, reboot app, delete cache, for instance) retaking the process and retesting after action/app reboot?
Does Wyze already have some automated testing utility for connectivity diagnosis/remediation in-house?
Not sure how substantial an “ask” this is but I thought I’d throw it out there.
Also, If anyone getting my drift can state this more elegantly/informedly have at it. T’would be appreciated.
We are working on updating the error messages to be more helpful. The scenarios are complicated. It is hard for us to be always accurate due to different network setup.
Wyze does have connection automation in house. They all passed before we release a new firmware. However the failures are mostly because of so many types of network setup (different ISPs, Telcos, router setup). That is the tricky part of the problem. If we have a consistent repro, we will be able to track down. Take the ‘LTE can’t connect’ as an example, most time it is one customer reporting issues → Wyze couldn’t repro → asked the customer (sometimes with a diagnostic tool)-> problem doesn’t show anymore or not enough info → fail to investigate.
I sympathize. I don’t know how you guys do it.
Maybe you should sell a Wyze Brute Force router that “guarantees” improved connectivity w/Wyze stuff OYMB - make another killing and reduce support demands. 
Did you imagine as a small child that you would be doing something like you’re doing right now? 
Now addressed in the manual:
https://support.wyzecam.com/hc/en-us/articles/360027279571-ThroughTek-User-Privacy
Does the camera detect the events on the edge? I thought the detection algorithm is done up in the cloud; hence you have to upload raw footage.
Currently we do AI work on Wyze cloud for 12s video and CamPlus video. Both videos are already uploaded to the cloud to store in S3 and AWS.
