Xiaomi camera playing on Google home hub sends stills from other people's homes
reddit.com
reddit.com
>"We’re aware of the issue and are in contact with Xiaomi to work on a fix. In the meantime, we’re disabling Xiaomi integrations on our devices."
...
>It appears Google isn't taking any chances when it comes to this issue, disabling Xiaomi integrations entirely. We reached out for further confirmation that this would mean a blanket disabling of all Mi Home products and were told that is the case.
Pretty annoying they have to mess up all my other devices, but at least it's being addressed.
[1] feedshttps://www.androidpolice.com/2020/01/02/uh-oh-xiaomi-camera...
I know it is not as convenient, but these cameras are getting scary. These are only the stories we know about. imagine who else is watching.
This is extremely selfish. What about your neighbors who walk/drive by your front lawn? You're doing your neighborhood a surveillance disservice.
As for people walking or driving by, they are in public and have zero expectation of privacy. I live in a school zone with a high school of 3500 kids across the street, most walk home. No one would never believe in a million years the crap they do to my lawn and the neighbors. They throw trash in my lawn, leave soda cans and bottles at the end of my driveway so I literally have to either stop in the street and move them or run them over getting into the driveway. They throw things in the back of a pickup truck in my driveway. They do this to all 12 houses on my street. It is nice to have footage in case ANY of this results in criminal damages. And it is legal.
So if that is selfish, then I am cool with that.
The issue I have is when the property owner isn't told who has access to the resulting still images or video stream, or is actively deceived about it. I'd be reluctant to use a Ring camera at my front door for that reason, and there's no way on Earth I'd install anything like that inside my home.
See, that's the idea behind the word "public." Nobody has to ask user lm28469 on Hacker News for permission to take photos in public.
This is a good thing.
And these are not good things. Both communal and private interests end up worse off in the long run with laws like these.
1: https://www.asmp.org/copyright-tutorial/photos-public-buildi...
most folks (especially us americans) accept personal propertly rights implicitly, so there's no need to vigorously defend them, especially when that defense implies caring only about yourself and not others.
How come Amazon and others apparently convinced millions of middle class Americans in the space of just a few years that they absolutely require 24/7 surveillance in and around their houses? Are you that scared of your compatriots?
It's even more puzzling than gun worship tbh
And for Mr "Irrational fears", no, I do it for entertainment, not because BigEvilCorp taught me to be afraid.
https://www.nytimes.com/2019/12/30/us/wyze-security-camera-b... https://forums.wyzecam.com/t/updated-12-29-19-data-leak-12-2... https://blog.12security.com/wyze/
Also the whole notion of an imminent danger for a semi-wild animal in a big house with daily renewed water and food is a bit weird to me. It seems like Amazon&co just amplify the existing irrational fears, don't you think so?
I have a nest camera pointing at my driveway. It's configured to use a zone that excludes the public sidewalk and street and only to alert me on seeing people. I really only expect alerts when my wife or the mailman comes and goes. The last time it alerted was actually the police walking across the property because I filled out an "alert slip" letting them know I was going to be gone for some time.
But the time prior to that was a homeless dude who ditched a bunch of stolen property in my yard and then came back to switch into his new stolen clothes. My wife went down and asked him to just go somewhere else mostly because this was the second time he'd done it and we didn't really want it to turn into a habit, much less for him to tell his buddies at the local homeless encampment "Hey, there's this great spot partially out of the public view...".
Unfortunately it turned into the guy screaming at my wife that she was a dumb bitch who couldn't tell him what to do, etc, etc. A police officer happened across all this as it was transpiring and ended up arresting the guy for trespassing. A big chunk of all this was caught on camera, including his using our driveway as a changing room the first time.
Hopefully that's the end of it and we never see this guy again, but if he comes around we have evidence of him trespassing previously and being told (on camera) to vacate the premises. It's just evidence if legal action needs to be taken.
If anyone knows something like this, a link would be appreciated.
Option 2: Search for "CCTV housing" to find boxes that look like old-fashioned outdoor CCTV cameras. Fewer size choices, but less weird-looking.
Or you could find a machinist. That'll be fairly expensive, though.
Lastly, you could probably make it using supplies from Home Depot, like PVC pipes + fittings and PVC cement, maybe some gasket sealer for any holes you drill. Probably the cheapest option of these 3.
I wanted camera's in the garage and back yard on at all times (people have wandered around the back yard before). Nest also costs per camera, so it would get expensive as well.
So it was a variety of issues and it was a compromise i was willing, or maybe forced, to do. I am happy with just the closed camera system and sending footage offsite, alerts and logging on with my VPN if needed.
The official, vendor-certified "fix" was that since the reply to this query contained the user ID, when calling this API you should always write a do-while loop like:
do {
accountsReply = bankCore.getAccountsForUser(myUserId)
} while (accountsReply.userId != myUserId)
This massive, embarrassing bug was not really documented anywhere, i.e. "silent information". You just "had to know" when writing code against this API that once in a blue moon, it could return data for the wrong user. But only in production, since the test environment was never under such heavy load it could trigger the race.A $300 atm, card-present withdrawal several hundred miles away (at a golf course country club) from where I had used the card less than an hour before.
Skimmer + camera for pin is sort of the only other explanation, and I'm fairly paranoid about checking for skimmers.
Rooted point-of-sale devices are also a possibility - that's what led to the big Target hack.
So POS systems store pins? I can't imagine them being certified if they do, or for what reason they might.
AFAIK, the POS hacks all ended up with cc numbers, no pins.
POS systems aren't supposed to store PINs, but a compromised one certainly could.
Anyone that thinks that cameras that are connected to "the cloud" don't give the company access to them is an idiot.
Although, if that were the case, I'd expect various partial mismatches to also happen.
What bugs me is having to add a new app integration to my Home every time someone buys us a smart device or light. A few cheaper brands I returned immediately after seeing how janky the app and setup were, and also because I wanted to minimize the number of integrations when possible.
I know someone who programmed cheap Chinese GPRS printers used in food ordering, he messed up his deployment script and gave every device the same ID - a special test ID that would return every single order no matter which take-away it was destined for. So basically, every order went to every take-away.
This scream of a lack of firmware QA more than anything else.
Ask me how I know this, um, exact case.
I found out when my new Rails 5.1 app which was using Puma, had to be switched to Unicorn so that it could work with our uniform platform for Rails apps. Puma threads are I guess pretty cheap and so are basically disposable, so they are created freshly all the time, but Unicorn process forks are made once per app-start because they're process forks, and incur some greater expenses.
So suddenly we noticed when switching to Unicorn that Class vars (those starting with an "@@" which are declared and have values in the class scope) are not reliably empty at the start of a request anymore, but usually had some value left hanging around from the previous request. Class vars are basically global variables so shame on us, now we know.
That previous request of course could have come from any logged-in user, so be careful what you store there! It's much easier to say "if the variable is empty, then initialize it thusly" and count on hitting that corner case once in a while, than it is to say "what is the order of my actual dependencies and how do I keep them ordered" – at least it seems easier until it bites you like this!
I wish NAT was never invented by Cisco.