Redbox left PII on decommissioned machines
Abandoned Redbox DVD kiosks have been found with years of unencrypted customer data still on their hard drives, highlighting how poorly many companies handle decommissioning hardware, especially during bankruptcy or shutdown. Commenters connect this to broader systemic issues: short‑term cost-cutting that defers secure disposal, weak regulatory enforcement, and the ease with which e‑waste can leak sensitive information. The thread also digs into the kiosks’ heavily abstracted C# codebase, using it as a springboard to debate overengineering, dependency injection, and the trade-offs between clean architecture, testability, and simplicity.
PII exposure and decommissioning failures
- Many see the abandoned Redbox machines with intact drives as a predictable outcome of poor asset decommissioning, especially during chaotic bankruptcy or “zombie company” phases.
- Some argue the original design (local DB, logs on kiosk) was reasonable for the era; the real failure is not wiping or collecting units at end-of-life.
- Others note it’s sloppy that a point‑of‑sale device retained customer records back to at least 2015.
Bankruptcy, liability, and regulation
- Multiple comments ask whether there are laws around secure decommissioning when a company goes bankrupt.
- Comparisons are made to toxic waste or old tires: cleanup should come before paying creditors, potentially via escrow or “Superfund for data spills.”
- Skepticism exists that regulation is enforced or that liquidators have the budget or competence to handle data properly.
E‑waste anecdotes and widespread data leakage
- Several stories describe decommissioned laptops, servers, and test kits with live VPN access, internal control systems, game source code, customer PII, and even trivially “encrypted” card numbers.
- Some organizations pile up hardware in storage because secure wiping “costs too much”; others pay recyclers whose destruction paperwork is described as unreliable.
- Commenters note how easy it is to retrieve gear from e‑waste streams via social engineering or small bribes.
Overengineering, C#/OO patterns, and configuration
- The discovered kiosk code (services, factories, interfaces, custom XML handling) is used as a springboard to debate “enterprise” overengineering vs. simple “just read the JSON/XML file” approaches.
- Some defend abstractions (e.g.,
IConfigurationService) as useful for testing, multiple config backends, and separation of concerns. - Others see single‑implementation interfaces, factory chains, and DI‑everywhere as legacy cargo‑cult that obscures what the code does.
Testing philosophy
- One side prefers pure unit tests with mocked dependencies for speed and determinism.
- The other side argues more realistic tests that actually read files or hit real paths are often simpler and catch real‑world failures better; mocking can drive unnecessary complexity.
Developer culture and “temporary” solutions
- Strong theme that “temporary”/MVP fixes frequently become permanent.
- Some call this acceptable if the solution is simple, maintainable, and solves real problems; others see it as a path to fragile systems that age badly.