> And in this case it's not clear that Amazon could have known the device was transferred.
Very fair statement. It's been a while but I've done a couple of these[0]. One comes to mind. The product was an internet connected home automation platform that predated the term "IoT". They had APIs with OAuth and their own system for managing layers of device pairing. It's a "hub"-like product; it could pair with devices for control and be controlled by things it is paired with.
In our case, we didn't have to think about this specific problem because of the fact their product handled that (and there was no alternative but to let it), so the service we wrote did little more than pass the data from point A(lexa) to point C(uster API) and back, through point B(loat) which did nothing but alter the inputs/outputs according to what "A" or "C" insisted on. It wasn't that the problem "couldn't happen", it's that it couldn't happen in the code I was responsible for[1]. "C", as you stated, provided authorization -- it was the authority and the only component in the chain with enough information to cause/detect/remediate this sort of problem.
With the additional context of there being a former/current ownership link at play here, it's a crazy common kind of bug -- everyone who's been on the "user" end of technology has experienced it[2]. I'm not surprised it happened. Quite disappointed.
I mean, this isn't hindsight. Do designers of IoT cameras[3] think that their customers are going to be anything less than mobs-and-pitchforks enraged if unauthorized users are able to view it? Sure, it matters a little bit if it's broadcasting the interior of a bedroom versus a rarely changing picture of the doormat, but that's 10% knocked off the mob. It's still a mob.
Handling ownership transfer correctly for privacy-sensitive devices (pretty much anything, anymore) should be the thought shortly after "let's connect a camera to the malware-net". Further, it's not an entirely unsolved problem (if imperfectly). You're always at the peril of your users, but you can make the process active rather than passive.
I purchased a product that had the user side of this handled pretty well (easily the more difficult of the two problems -- "they'll make a better idiot"). It was nothing exotic -- simply applied "default deny" in a manner that fit with the problem. IIRC, it was a SmartThings Hub that I purchased this from my brother-in-law, who had connected in once, used it for a month, disconnected it and tossed it in a box. I did the hardware factory reset (he couldn't remember the password) and expected the usual routine you'd get with a router.
No dice -- after factory reset, it defaulted to denying access until a device-specific code, which is printed on a card, stuffed in the manual, neither of which I had. I had to call their support line, provide information about the previous registered owner as well as a few values from the bottom of the device (guessing it's used to calculate the activation code). It was pretty solid as far as minimizing accidental disclosures like this -- even if the user forgets to factory-reset -- as a hub, it's going to reveal a password-protected interface that's protecting PII about the previous owner and configuration about a bunch of devices they owned that likely wouldn't work even if they were all sold together to the same person. The previous owner could control the hub with their password which would allow them to ... change their PII and see error messages that occur when he/she tries to control the irrelevant devices it's now configured for?
That process isn't good enough for a camera (if it's wired, or previous owner/current owner used open wireless), it could be plugged in, DHCP itself an address and become available to the previous owner through their cloud account.
Unfortunately, that extra step is costly. If the activation code is generated in a cryptographically sound manner (some combination of a hash of the values I had to provide signed with a private key by an HSM?), that's going to be added software development/infrastructure costs. Then there's handling idiot customers (like me) which will require some way to authenticate me -- and you're probably going to end up needing a call center to handle all of them, because all they see is that the damn thing they bought isn't working.
But that's just it -- (other than us) at no point had it crossed the customer's mind that the camera could have a privacy "surprise". They see "Camera" and "For my home" and assumes any product sold at a major retailer must get the basic feature of "don't accidentally expose the customer's genitals" right[5] (joking, though Amazon's Echo Show is often marketed sitting where your bedroom alarm clock would be). Even more fun is that the customer is far more likely to encounter that activation problem than they are a "genital disclosure" problem and are unlikely to understand or appreciate that the little bit of grief is for a "good reason". The business side will be able to calculate the costs of implementing activation but will struggle with the cost of not implementing it. It also leaves room for a gamble. Many things we aim to prevent are things that never happen -- the software isn't interesting enough to attract research into attacking it or the right set of "bad things" didn't happen to discover a vulnerability accidentally. The circumstances are then: (1) Pay a lot of money for something that might not happen or (2) Save the money, cross our fingers. Sometimes the money's not there and (2) is the only option. But for a product like this (1) is the only viable choice -- a single high-enough profile incident for a small enough company is enough to eliminate the company and if the company is successful, it sells more devices, which exceeds the preventative capability of crossed fingers.
[0] I inherited the voice applications that my company developed for others' commercial products - all but one extremely large deployments.
[1] That's not passing the buck. We didn't have their code, access to their code, or any expectation that we could get it if we asked nicely. They gave us documentation to cover the calls that needed to be made to make it work.
[2] And when it's presets on the used car you just bought, it's no problem.
[3] While writing this, I looked over at my desk. Apparently I am ... well ... my parents are/will be Wyze owners. I purchased them a camera to provide a view of Lake Huron from the second floor bay window. Haven't used it, but it had the features I wanted (security wasn't one of them; it's meant for sharing and I'm isolating it with the rest of the IoT gremlins), they're inexpensive as heck but don't look tacky or cheap.
[4] I'm going from memory - I purchased this years ago.
[5] Two Mandatory Features for IoT cameras: (1) Records video customer can watch on any internet-connected device. (2) Ensures customers genitals appear only on authorized devices. The importance of that second feature cannot be underestimated. Might want to do (2) first -- I'd, personally, rather own a camera that took no video at all than one that was good at sharing videos all by itself.