Redbox left PII on decommissioned machines

Take this as a lesson. If you've been a dev long enough, you've worked on a project knowing that how the project is being done isn't the best method with every intention of going back to make it better later, but not at the expense of getting the MVP up and running. You'll also have seen that never actually happening and all of those bad decisions from the beginning still living all the way to the bitter end.

I'm guessing not one person involved would have ever imagined their code being left on a machine just left out in the open exposed to the public completely abandoned by the company.

One just wonders if the cooperative-multitasking BASIC implemented in this machine really was necessary for an MVP. Other than if that just happened to be the sort of programming that the developer at the time was familiar with.

Also, this really is the 'engineering' discipline with the lowest level of craftsmanship and regard for rigor, isn't it? Because the failures are usually intangible, not directly life-threatening.

When a developer says “this is a temporary solution” they mean “this is a temporary solution forever”.

The beta version works fine, lets just keep it.

There is nothing more permanent than a temporary solution, and nothing more temporary than a permanent solution.

They might have had the most perfectly developed decommissioning process. And nobody is going to care when their paychecks stop showing up, and everything suddenly gets trucked-off into receivership.

Given the era and constraints, I don't see how it was irresponsible or 'sloppy' to have a local database on these things. This most likely is not on development.

Never make the "Proof of concept" so good it is actually usable.

This.

I often wonder what was left behind when the financial crash happened. Watching documentaries and movies about it, it looked me like several large banks and insurers closed up shop overnight, and people were leaving the next day with boxes containing their personal effects.

They mean temporary for them

The good practice of last year is the bad pattern of today.

That's very true.

When a customer has a problem, you create a solution to it. Often the problem is part of a much larger space, so you tend to have discussions of all the possible features you could implement. This is a necessary step to gain knowledge about the problem space, but it can lead you to think that the solution have to cover it all

Time restraints leads to a "temporary" feature to solve the customer's immediate need. Most of the time it turns out that all the other features are neither necessary nor important enough to spend time on.

Projects without time restraints or focus tends to create a complex system that will "solve" the entire problem space. Most of the time it turns out that our assumptions are wrong and we need to do a major refactoring.

"Temporary" solutions may not have the best code structure or architecture, but it is not necessarily a bad technical debt, as many new developers to the project seems to think it is. Also, the time restraints of a temporary solution encourages the developer to create simple code and not "clever" code, because they can always blame time restraints for their lack of cleverness. If the code has been mostly unchanged for years, somewhat maintainable and solves the customer's problems, it's not really a problem.

Words to be forever-tentatively employed by :)

I think you're right in general -- that is, regardless of the original company's practices, the entity selling off the assets should be required to do that responsibly -- but then:

> the unit I've got an image for has records going back to at least 2015.

Whether or not it's "on development" -- that's sloppy. Like how it would be a problem if your preferred grocery store kept your details on the cash register you checked out through almost ten years ago. It's a point-of-sale terminal holding on to high risk data for no reason.

At least in web development. There's a weird time horizon there, the good patterns from a decade ago are often still good practices.

Picking up the latest and greatest web stack today will likely be a rotting, unused stack next year. Pick up rails or django and it will be largely unchanged and you'll still be able to hire for it.

> and everything suddenly gets trucked-off into receivership.

That's the problem. These things aren't getting collected and trucked off. They are just left rotting in their installed locations. I'm pretty confident that you could just show up to any of these with a tool box to just start opening one up to take out whatever you wanted from the insides, and not one person would question you. They already said they don't care if you never returned any discs you had in your possession, so nobody would care if you emptied their inventory of discs within. And until now, I'd wager not one person inside the company ever thought they might be vulnerable to a PII attack like this either.

I agree. Temporary / bandaid solutions are totally great if they are straightforward to implement AND unimplement.

I recall being surprised to see people using a Redbox in the grocery store. Like, wow, (a) this company still exists, and (b) ppl still watch DVDs. And that was years ago. I think it's not unlikely the company was already in total zombie-mode by 2015.

The host locations are pissed off that the machines are sitting there taking up space and using electricity. They certainly aren't going to be happy with someone opening it up and making a mess. Or potentially creating some sort of additional liability for them.

But if you show up with a van or a large truck, they'd probably pay you money to take the whole thing off their hands. And you can tear it apart in your own garage.

The end of Chicken Soup for the Soul media (who owned RedBox and Crackle at the end) was a complete shit show. I’d be unsurprised if they just walked away from the DVD boxes leaving the whoever had them on their property with the job of dumping them.

CSS just stopped paying vendors before the Redbox acquisition to make their balance sheet look better then just never paid after that until going bankrupt a year later. (My company was a vendor who had to get our attorneys involved to reclaim some payment prior to their bankruptcy and will never get the rest)

I’ve seen a bunch of these SPAC style (there’s usually some sort of penny stock starting point so the company is publicly traded from the jump) rollups of bankrupt or failing media and entertainment brands over the years and they all blow up.

Theres probably lots of great robot disc handler stuff in those boxes.

Write the proof of concept in a language that the company doesn’t want to support. Erlang, Haskell, Prolog.

There was an article in some source (sorry, I forget which) that interviewed a person somewhere in the Southeast US that has been paid to remove a dozen or two of them. It had some photos of the inside of the machine. You should look for it!

There's a Discord where people are sharing ideas on sourcing and modifying the kiosks. https://discord.gg/ZNXy722W5t

> taking up space and using electricity.

how hard would it be to unplug the units? if these things are on a shared electrical circuit with anything else in the store, then that's on them. If they are separated, then just flip the breaker. otherwise, there's going to be j-box some where near the thing connected to some conduit. ten gets you twenty that there's some wire nuts in that j-box that could be disconnected in less than a minute.

also, just show up with a clipboard, and if anyone asks you, just say you were hired to collect certain items from within but not remove the entire thing. just print up a fake work order. i don't think i'm thinking too far outside the box on this one.

> One just wonders if the cooperative-multitasking BASIC implemented in this machine really was necessary for an MVP.

I have a feeling that someone already had that hammer ready and was in search of a nail. :)

Might be case of a VB6 programmer who graduated to .Net C# but still misses the good old days.