Redbox left PII on decommissioned machines

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.