Well they sold services which made use of a vulnerable version of struts.... You can argue services != products, but It could be argued a similar approach could apply.

The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem.

There's an externality here in that the people who suffer the loss have no part in the transaction (they are neither buyer no seller) so have no way to, in an economic sense, impact Equifax's behaviour, which does lead to the idea that regulation could be an appropriate approach.

> The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem.

Perhaps, but it's a different problem that product liability.

> which does lead to the idea that regulation could be an appropriate approach.

CRAs are already regulated.

If I can jump ahead a little, are you saying that bad (e.g. fraudulently-inserted) CRA data cannot rise to the level of actual damages?

Who's doing the fraud? Is it Equifax, which is in good faith recording the information provided by its customers (credit companies, banks, etc)? The credit company that is reporting in good faith to Equifax (or another CRA), but is tying it to the wrong person because an account was fraudulently opened? Is it the person who used stolen ID data to open the account? Is it the thief who originally stole the data?

The US doesn't have a data-protection law, but how can you say their recording of the information is in good faith if they allow unauthorized people to make spurious changes via their systems and security practices?

> allow unauthorized people to make spurious changes via their systems and security practices?

I don't follow. Who's the unauthorized party that's "allowed" to make spurious changes via their systems and security practices?

Those who use the holes in their infrastructure, did you see the story about a database being accessible with default credentials? There is some question of scope for that particular issue, but it bodes duplication in the company's practices elsewhere.

You mean the web site that didn't have any non-public data, and was actually not in active use for 3 years? I agree that was sloppy, but the site didn't have the level of security requirements that one of the main sites or their internal network had. Do you put a $100 lock on a $5 bike?

And how was this "allow[ing] unauthorized people to make spurious changes"? No data was changed in the breach.