Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CCPA Will Hit Dev Teams Harder Than GDPR

tonic.ai

Post reply on HN
Print view View original

81–90 of 179 posts

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#81

Post by jancsika »

nickpeterson wrote: post #60
jordigh wrote: post #54

Earlier quoted context omitted.

One of the most famous "legal hacks", Richard Stallman's copyleft, had to be rewritten by a lawyer. rms wrote GPLv1 by himself and you should never use it. GPLv2 is the version that was actually vetted by a lawyer. A similar thing happened with Perl's Artistic License. Its version 2 is basically also a lawyer-approved rewrite. In other words, hackers, don't try this at home. There are professionals who can do this fo…

I find it somewhat sad that law is basically a guild where arcane language is used to gatekeep what should be a much more straightforward exercise.

I find it somewhat sad that programming is basically a guild where arcane language is used to gatekeep what should be a much more straightforward exercise.

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#82

Post by icoe »

casual_slacker wrote: post #12
gwbas1c wrote: post #4

Great article, until the end. Who uses PII in test data derived from real customers? That's just an absurd practice to begin with, and no one who takes security seriously would even consider doing this.

We used a similar trick, not for testing, but the ability to download the prod database and debug things locally. We hit scaling issues before PII, so coworker built a system to generate real-ish DBs with only one customer's data. And then in a future version, sensitive fields were filtered or replaced with mock data. Not sure if there are better, less engineering effort ways of doing this, but it was a great tool wh…

Makes a lot of sense. I actually think leveraging your prod data to create a test environment is one of the best approaches, as long as you're mindful of privacy. Full disclosure: I'm a founder of tonic.ai and we make tools to make it easier to create synthetic staging instances from production environments.

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#83

Post by flukus »

alkonaut wrote: post #39
gwbas1c wrote: post #4

Great article, until the end. Who uses PII in test data derived from real customers? That's just an absurd practice to begin with, and no one who takes security seriously would even consider doing this.

I have never seen a “dev” instance of a DB that wasn’t just a snapshot of the prod DB from earlier. I admit haven’t seen many - but I have seen zero of any other kind (e.g. anonymized or synthetic)

I've done this plenty of times, but you can anonymize the data fairly easily and get the benefits of both.

The flip side of the coin is dev databases not being representative of production, this can cause performance issues. "It works with 10 rows on localhost, why doesn't it work with a million in production?".

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#84

Post by [deleted] »

thaumaturgy wrote: post #74
jarvuschris wrote: post #37

Counting an IP address as PII is kind of crappy, you need a court order to turn an IP alone into PII. Operators should be free to log traffic at the network level, PII should only come into play once you're asking someone to provide personal information.

There's been a lot of FUD surrounding the logging of IP addresses for network diagnostic and abuse purposes as a violation of GDPR (and now CCPA), but I'm not aware of any cases where that alone was sufficient to cripple a business. Until I hear otherwise, I'm going to gamble that for now that's not the kind of reckless mishandling of personal information that regulators are trying to crack down on.

[deleted]

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#85

Post by sbov »

Karrot_Kream wrote: post #62
nickpeterson wrote: post #60

Earlier quoted context omitted.

I find it somewhat sad that law is basically a guild where arcane language is used to gatekeep what should be a much more straightforward exercise.

It's not. It's the equivalent of saying "I can do this better" and producing unreliably, buggy code. Sure you can, but a more experienced professional can point out all the corner cases you missed.

Then when it fails, you blame the programming language rather than your experience in programming.

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#87

Post by weaksauce »

recursive wrote: post #72
saalweachter wrote: post #61

Earlier quoted context omitted.

IPv4 addresses are only 32 bits, which makes building rainbow tables almost trivial.

I thought salt was supposed to be unique per hashed value. Rainbow tables don't work in that case.

that only work if you had two pieces of information. username and password works because you can find the salt value associated with that username and then use that for the password hash. an ip would still require an unhashed thing to lookup to get the hash if you did it per ip address. for this you might be able to get away with using a sole salt value for all ip addresses but even then if you get hacked it would be trivial to write a script to compute the rainbow table when you steal the salt value.

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#88

Post by ehnto »

jarvuschris wrote: post #37

Counting an IP address as PII is kind of crappy, you need a court order to turn an IP alone into PII. Operators should be free to log traffic at the network level, PII should only come into play once you're asking someone to provide personal information.

Yeah it is odd. You decided to hit my server, I should be able to record the occurance. How am I suppposed to deflect DoS attacts if I can't maintain a list of nefarious IPs. I know that's a fairly low tech attack, but they still happen constantly. Is Fail2Ban no longer compliant?

I wouldn't be surprised if some policies pertaining to record keeping in some sectors contradict that requirement as well.

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#89

Post by Novashi »

heavenlyblue wrote: post #73
Novashi wrote: post #41

Earlier quoted context omitted.

>You on the other hand are hosting a website with some sort of form that people input PII into. That's what cloud providers do! If there's a spirit-of-the-law that is supposed to protect them, this would be a good time to write that in!

Do they specifically mention rental cars in the code of law, when they say that the driver can't drive over the speed limit?

"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.

Re: CCPA Will Hit Dev Teams Harder Than GDPR

#90

Post by saalweachter »

amenghra wrote: post #80
gregmac wrote: post #71

Earlier quoted context omitted.

Yeah, though a salt would at least mean you'd have to rebuild the table for each site/database/whatever. However I'm having a hard time seeing how to really protect against this. The IP is a an identifier, so unlike password salt (where the user is the identifier) you need a way to know what the salt is to hash the IP, and it needs to be consistent. You can do a lookup table of IP-to-salt, but this either gives away…

You could encrypt instead of hash, and then have some policy (e.g. the decryption library/service/piece will only allow decrypting ciphertext newer than 30 days). If you need the ability to group ciphertexts without decrypting them, you could create a scheme which will make cryptographers cringe, but could be justified in this specific case.

For large sites, you also have the risk that you might be able to say something statistically useful about the plaintext.

For instance, you can probably assert things like which IP blocks are likely to comprise most of the entries in the table or which IP blocks or addresses cannot be in the table.

That just makes me all sorts of uncomfortable.

Post reply on HN