I think this is the answer:
Based on the illustrations and descriptions in the blog post and video, that much seems pretty clear and unchanged, though they could probably set a lot of users’ minds at ease if they were just more explicit about it.
I think some reasonable questions are being asked here, and I really hope Wyze uses the discussion in this topic to create a FAQ for VerifiedView/SightSafe in the Help Center.
I certainly agree that they are very reasonable questions but I suppose I’m thinking about it in terms of what has already happened…
The app and firmware have been doing this for several weeks and NO ONE has reported an inability to share a video to someone who has not explicitly been shared to…either by sharing from the cloud or by sharing a local file from your phone.
Maybe this feature was NOT turned on… but otherwise, if it has been on the whole time, then I think people are overreacting. You can literally test this right now… save a video to your phone, Share it from your phone (not the cloud) … can the person view it? Then VerifiedView is not in play.
Am I oversimplifying this? I could be totally misunderstanding how it works. I did watch the video and understand encryption. I saw nothing that was saying it would be encrypting files on your device that would require the Wyze app to decrypt for viewing and sharing. So, saving to your device is what sets you free. Sharing via the Wyze App is a whole other story, and I believe what VerifiedView is talking about. It is for cloud-based security and access to protect against videos being seen by other people within the app.
You can encrypt data at the file level, the file system level, the application level, and the networking level. I believe VerifiedView is working only at the application/network level. Once you remove the file out of the ecosystem, you lose all security. If the file was encrypted or marked in some way, then the person on the other end would need the Wyze app to “de-crypt” the file to prove who they were. That is not happening here whatsoever. And the file would not be in it’s native video format. It would have to have a different extension. Wyze video files are .mp4’s. There is nothing built into that format that protects it. If I have the file, I have the file. I can see it and use it. It’s not like Adobe where encryption and security can be enabled on the file level.
You’re overcomplicating what Wyze is doing. The video format is already compressed. You can compress the files again but you won’t gain any more storage savings.
What this is doing is adding metadata to an existing file format, specifically, adding ownership/security metadata to a video file, so they can check if the person playing it has the authority to do so. However, the devil’s in the details, that’s why we’re asking questions.
While everything works while you’re still within the Wyze ecosystem, these question are asking, what if you are no longer there? What for example happens if a Wyze competitor introduced a superior camera and I switched brands? What happens to the clips that I already downloaded? You might be OK with dumping those old clips, but not others.
I’m confused. I’m not talking about file size / compression. I’m talking about encryption/security. Putting metadata on a file does not protect it when you download it and have the actual file.
That’s my point. If you have downloaded this file, you HAVE the file and will not lose it. Wyze can’t stop you from opening it or delete it a year from now.
If you take that .mp4 file, copy to Google Drive, download to another computer, copy to a USB stick, and then email it to 5 people… ALL those people will be able to open it.
This is a security measure WITHIN the Wyze App.
You download the event video (.mp4). You have it. It is available and will always be available.
Other than actual encryption, if I can pull that file out of your application (ANY APPLICATION EVER MADE). I have that file. Applications have to STOP downloads to prevent the file from escaping so they can control access within the application. They know that if I can pull the file out, it is mine.
You aren’t stopping me from getting into it once it leaves the application unless it’s encrypted or has file-level security like Adobe.
This is a file security issue, not a file size issue.
Prove me wrong…
If VerifiedView was stopping videos… playing this video on ANY DEVICE without the Wyze app, would not work. That is not what is happening here.
This is not complicated folks. You can prove it right now with that scenario above.
Yes, it works now. That’s not in dispute. But will it work next year? I want that statement to come from Wyze itself, not from conjecture from anyone.
For example, Wyze is saying that VerifiedView works from the older app versions for now. But probably not later. Is there some switch that Wyze controls?
[MOD EDIT]
I think so, and what I suggested was more of a “peace of mind” thing: Sometimes even when the answer seems apparent and fairly obvious because of the way something is observed to be working it can still be helpful to some people to have those kinds of questions explicitly answered and spelled out. As a volunteer, I selfishly would like to see something like this so that I can have an official source to cite and point other users to when they have those questions, but I also think something like this would align with Wyze’s stated philosophy of being transparent and being friends with users.
Yeah, I think so. I was messin’ around with adb a few weeks ago and saw references to prod-sight-safe-auth.wyze.com in the logs. I just assumed it was already in use because of that observation and the notes in recent firmware releases.
I think that’s another key statement. My understanding of VerifiedView is that it’s operating between the user (user’s devices) and Wyze’s servers. Once you take content (videos) and save it locally, there is no longer any Wyze middleman that prevents your doing whatever you want with it. Security of the video (or whatever) at that point is your responsibility as a user. It’s kind of a “Who had it last?” game at that point.
That’s not how I interpret this statement:
I believe that’s saying that VerifiedView is not active in older app versions, so they’re not enforcing this additional security check when someone tries to access cloud content with an older app, but at some point they will enforce this additional measure, and at that time the older app versions will no longer be able to access the content that is coming from Wyze servers.
My background is working on computers beginning with x286. I became an MCSE on NT 4.0 in 1999 and later upgraded to Windows 2000 / Active Directory. I can subnet in my head. I have worked on Storage Area Networks that require making files systems, migrating data, preserving data (Disaster Recovery / Business Continuity) using EMC equipment (2 PB worth). Even designing a system to replicate data with a Recovery Point Objective of 60 seconds before the Disaster hit… and the Recovery Time Objective of 15 min to being online again.
So when I tell you… you download that file on your phone it’s yours, it’s yours.
There is NO magic encryption that can follow this file around and “take it away” from you later. It defies the actual science of file systems. That’s MOVIE made up stuff.
When data is in the wild. It’s in the wild. No getting back. I download a video to my phone from Wyze, my phone AUTOMATICALLY uploads it to Google Photos! I can immediately DOWNLOAD from google photos to a flat file again to my Google Drive and then to a USB stick.
Are all of you thinking that after all that… Wyze can disable the video?
What you are describing, e.g. the file being disabled and NOT YOURS anymore at a later date; would be the COOLEST thing ever if it were true. As a computer nerd, a time bomb file that I can control the encryption to at a later date is genius. That is what everyone is envisioning here.
It simply doesn’t exist my friends. That’s why you have to be careful with your data. Once it’s downloaded [MODE EDIT].
Let Wyze answer, because that’s binding. [MOD EDIT]
[MODE EDIT]
I understand that you fear what you don’t understand. That is human nature.
Do your own homework. Educate yourself on the basics of files, file systems, encryption, and DRM.
What everyone is describing here is digital rights management. The movie industry tried this. It was a failure.
[MOD EDIT] There is plenty to question in terms of security. Nothing to question in terms of digital rights to your videos. The end.
For this, I only care for official Wyze position. There’s must be a reason there’s silence.
[MOD EDIT]
All,
Please ensure the community guidelines are followed. Especially: Sometimes We Disagree And That’s Okay.
@p2788deal , this is a user to user forum and Wyze may or may not respond.
All this is my understanding and somewhat confirmed by Wyze:
The VerifiedView will ensure no other users will be able to see your video when logging into the App or the Portal. There is a check against the Meta Data to determine if you are permitted to see the video. This has been put in place overtime and already existed on some camera’s and called SightSafe.
Downloading events and saving them locally to your computer / Phone will not cause any issues now or in the future as the metadata is not something that will cause other viewers to stop you from seeing the video.
This is not encryption of the video it is security against who can see the video.
@WyzeJasonJ , can you confirm
Yes, the downloaded clips will play for as long as you have them downloaded. VerifiedView has no bearing on that.
Yes, it works now and it will work next year, and all the years after that. Your downloaded video is yours.
That is completely correct
I didn’t even mention the word encryption. Check the thread.
My bullets were to all, not directed at you.
I think @WyzeJasonJ answered the questions you had.
VerifiedView has been slowly rolling out to most cameras over the last few months and is now on our most popular models … It will continue rolling out to more cameras in the coming weeks.
Will this include all camera models? Or will older camera like the V2 be left behind, and no longer work in the app?
The video says that the Pan Cam V2 may not get the update due to hardware limitations, so it may stop working in the app. If that is the case, then please let me view my V2 without verifying the id.
So now we know the truth about what REALLY KILLED Wyze Bridge.
Muh muh…
I definitely had not started to use it, yet, but it was on the radar…
This created a whole lot of drama that didn’t need to happen or exist. And you could have worked with the developer(s) to resolve these issues. Or just flat out said, we broke it, “for security.” And no we ain’t unbreaking it. Oh.. no need to give me the PR and corpie speech on the why this wasn’t possible like the way this whole post starts off.. You are just digging a deeper hole on that.
Truthful transparency is a must.
The goals here may be good, but the means are leaving a little, no a lot, to be desired. Honestly I am not sure how it solves the issues it supposedly is fixing (And before any one around here wants to start a credentials battle, I can list a long litany of gibberish in that vein, don’t mean squat. Starting with Why YES I did stay a Holiday Inn Express last night! 
)
I’d really like to keep alot of things in one system.. and hence why I am using wyze..but I can see on the horizon here, that I am likely going to have to split things off. Sigh. Cameras on T, sprinkler on wyze, and security on TBD. The next moves here will make those choices come into focus. I can see where this is headed. Might be time to look for some deals to test out some things.. sighh.
I really had thought a lot of the warts of wyze had finally been burned off.. I see I am wrong, very wrong.
PS: Slow mode, 1hr wait for replies.. OK.. we’ve really hit the touchstone on things here. Clearly you know this is going to upset users.. yet… ok.. I think this answers many things…sighhhh…
Possibly, but Docker Wyze Bridge uses the API and has you enter in an approved username and password and API key, so it should have the appropriate credentials to view the livestream. Also, there are lots of people who have been able to get DWB to work by changing a setting and making sure the cameras and the DWB Host are on the same local Virtual network, etc. So if VerifiedView was the problem, then why are so many people able to use it by updating their network settings? That leads me to believe that is not the [only] problem or everyone would be locked out of DWB, and that isn’t the case, so I lean toward thinking that may not be the issue. However, while trying to support Verified view, they may have made some other changes to their authentication process that is messing up what DWB had in place. I agree that is definitely a strong possibility.