Probably a race condition. I once worked at a bank where the core banking system had a bug where if you asked account data for user X it would about once in a thousand queries return data for some unrelated user Y if the system was under a high load.

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.

So, OT, but I wonder if this explains my recent atm withdrawal error on the part of wells fargo?

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.

I've seen photos of some very convincing skimmers that I'd have no hope of detecting despite being pretty paranoid about them myself.

Rooted point-of-sale devices are also a possibility - that's what led to the big Target hack.

I finally saw a gas station with a chip and pin reader at the Bucees in South Texas, and my spirits were uplifted considerably. Gas stations seem to be both the ideal place to install a skimmer and the companies most dragging their feet upgrading to the tech that will eventually make card skimmers obsolete. It's frustrating how behind we are on this.

I pick gas stations based on whether they support contactless payments.

Going far afield now, but a skimmer isn't going to get my pin, right? This was a card-present, atm cash withdrawal that happened.

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.

There are skimmers that fit over the PIN pad, or that have cameras pointed at it.

POS systems aren't supposed to store PINs, but a compromised one certainly could.

This is all because of NAT. I bet that to bypass it they have various servers where your cameras connect to and the image is streamed through them when you use your app to view it. When you're connecting you just see the last frame stored that previous user was viewing. Their fix probably will be to just delay the app display so it is not showing this.

Anyone that thinks that cameras that are connected to "the cloud" don't give the company access to them is an idiot.

How could this be a race condition? if you ask for a specific stream channel why would you get other stream channels? even if its for a thumbnail preview, the software behind this has to be a clusterfuck to begin with

E.g. there could be a cache that (incorrectly) returns a reference to a cache item without any locks being held by the client and reuses cache items on eviction. Then if an eviction happens before the client is done with an item, there is a data race between the client reading the item and the item being updated into the new, unrelated, cache entry.

Although, if that were the case, I'd expect various partial mismatches to also happen.

We recently got a roborock for christmas, which I love btw. From what I recall some of the features of the app still say they're in beta, and they made it very clear. I'm not saying it makes it okay, but I'm curious if this part of the issue.

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.

The fact that most of the images are distorted in some way seems significant. Perhaps faulty firmware was sent out?

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.

More likely re-used cache.

Or a lambda that didn't initialize, say, the customer ID and got it from the last run because of some edge-case in calling it.

Ask me how I know this, um, exact case.

Yeah, you can get that, "um, exact case" too, with Rails in 2018, ask how I know it's easy to trip over while switching between web servers like Puma and Unicorn, because of the different way they each handle objects threading/forking.

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!

yep, most people are behind NAT and they are using servers to be able to fetch data that way. Those servers are reused by all of their customers.

I wish NAT was never invented by Cisco.