Not really. The victim here is the people whose information has been distributed, not the system (and the people running it) the information was exfiltrated from.
replyIf we are going to use an SA analogy, this is closer to the recent case of a hotel chain where there were several instances of staff giving “randoms” keys to rooms that they should not have. Best practise procedures were not being followed, the ne'er-do-wells took advantage of this, someone else suffered as a result.
If you process personal data, you must secure it against attacks. Are you suggesting that they could just put the addresses of their customers on their website with a warning not to download them, and if someone downloaded them anyway then it would be the fault of that person that they were leaked?
replySociety hold a strong double standard when it comes to the notion of blame in criminal acts. In some cases, it is fully put on the criminal. In other cases, it is put on victims of the criminal. While each case can use logic to try to defend it, they are different standards not used consistently. Trying to call out this double standard is a sort of act of profaning the current social norm and not appreciated by most, no different than trying to attack the dominant moral system 500 or 1000 years ago for inconsistencies.
replyIf we were being consistent, then to your later question, yes. But pointing this out is picking at society's reverse scale.
According to this logic, anyone using PHP should also not be processing personal data, and of course Java, and also Javascript, and any other language that has had a huge zero-day. In NYS, your name is considered personal data, so these libraries should not have any digital collection of the names of their members let alone any online services. Although, I'd prefer we start with Meta, Amazon, Alphabet, Apple, etc when it comes to making them lose the right to storing all personal data every time they have a vulnerability.
replyThere is a difference between being hit by the exploit of a zero-day and being hit by the exploit of something (incorrect security implementations) that has been known to be incorrect for years, decades even. The zero-day in PHP is not your fault (unless perhaps you wrote or maintain that bit of PHP) but bad security implementation using PHP (silly example: not bothering to hash password because it is easier and allows you to allow for typos which is convenient for the user) is ultimately the organisations fault.
reply