"Process PII" is incredibly vague. You could define that in a hilarious amount of ways with the amount of complexity we introduce to our software products, especially with code we don't even write ourselves that widens your security surface.
This is especially true if you use a service that allows others to inject code into your code base. If NPM has a security failure that leads to a breach at a company, who is at fault? Both? Or only the company that chose to use the code? An NPM package might be processing PII after all. Does that mean NPM can never be held responsible for security breaches?
Secondly, your example would be backed up by historical cases and this law is brand new, so it is not clear. I'm not even sure how you guys can confidently argue that the new law ISN'T outright vague.
>> You could define that in a hilarious amount of ways with the amount of complexity we introduce to our software products, especially with code we don't even write ourselves that widens your security surface.
You could define in a hilarious amount of ways in which your chef can pee in the broth you ordered in a local diner. But it generally doesn't happen, does it?
