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

How GDPR Will Change The Way You Develop

smashingmagazine.com

Post reply on HN
Print view View original

601–610 of 710 posts

Re: How GDPR Will Change The Way You Develop

#601

Post by emilfihlman »

ahoka wrote: post #197
Jakob wrote: post #159

Earlier quoted context omitted.

The legal ramifications of storing IP addresses didn’t change with GDPR. You should already have them anonymized since they count as personal data: Google Analytics ( https://developers.google.com/analytics/devguides/collection... ): ga('set', 'anonymizeIp', true); Web server (here nginx, https://stackoverflow.com/a/45405406 ): map $remote_addr $remote_addr_anon { ~(?P \d+\.\d+\.\d+)\. $ip.0; ~(?P [^:]+:[^:]+): $ip::…

You can also irreversibly hash sensitive data it so you can still use it for debugging.

IPV4 is only 4 bytes. Hashing through all 4 milliard is trivial.

Re: How GDPR Will Change The Way You Develop

#602

Post by emilfihlman »

chii wrote: post #556
ebcode wrote: post #302

Earlier quoted context omitted.

OK, but what the parent is suggesting is that someone might store someone's personally identifiable information on "the blockchain", thus making the entire bitcoin network in violation of GDPR. It's a fairly on-point criticism, IMO.

it's not Bitcoin network that's in violation, but the company that owns the transaction in which the data is in. let's say I'm a shop and i allow btc payments, but I include the customers info in the transaction or something to such an effect. then I'm in violation, and must pay a fine (since I can never delete that info). The network has nothing to do with this, and nobody else on the network is party to the violati…

So just paying a fine is enough to make the issue go away and the users privacy is bought out legally?

Now we have a way to estimate the cost and we can just put that on top of the cost of using the service.

Boom, privacy bought.

You don't realise how absurd GDPR is?

Re: How GDPR Will Change The Way You Develop

#603

Post by lawik »

ncallaway wrote: post #485
boredatwork wrote: post #325

Earlier quoted context omitted.

Sure I delete files that I don't like, but I don't typically rewrite all my old backups to purge them from there too.

This is my biggest question about HIPAA and GDPR about deleting specific user records and data. How are others planning on deleting data from all backups. It seems like any automatic process that modifies all existing backups has the potential to accidentally corrupt all backups in the process. Is there any safe way to safely delete a record out of my prior database snapshots, or is there a reason I don't actually ne…

Do you maintain your database backups indefinitely? If they rotate out after a month or so you will likely be inside the realm of what GDPR considers reasonable compliance. The live data is removed ASAP and the data will rotate out from the backups in a reasonable time frame. At least from the legal advice we've had.

We have no plans to retroactively fix our backups. But we will have to make damn sure that if we need to use a database backup we do not reintroduce user data that we've purged. For that purpose we will have to maintain a list of which users have been purged until the backups rotate out. According to the advice we've had, this is acceptable.

Re: How GDPR Will Change The Way You Develop

#604

Post by FlyingAvatar »

ahultgren wrote: post #598
emilfihlman wrote: post #596

Earlier quoted context omitted.

Holy shit what. IP logging is not ethically ambiguous in any way. It's 100% okay. You chose to connect to that IP. If you don't want your IP logged don't send an IP packet to that address. It's very simple. This is beyond ridiculous. The entitlement I see here is cancerous in the literal sense.

Holy shit can't you read up before complaining without knowing the details? There is the exception that you may use and store data that is necessary for providing the service. Thus, since ip is necessary for talking to a server, you don't need to explicitly ask for consent. However you MUST NOT do anything else with that IP, like logging it for longer than necessary or tracking users across sites (without consent). W…

You knock on my door and I write down that you visited me.

Why is it somehow reasonable to compel me to forget that interaction existed?

Re: How GDPR Will Change The Way You Develop

#605

Post by adrianN »

nrjames wrote: post #505
njl wrote: post #494

Earlier quoted context omitted.

The user can request I delete all of the data related to them without “undue delay”. Are you ready to purge all references to certain IP addresses in your logs? Don’t forget backups. GDPR blows up a lot of assumptions we make about writing software and managing servers. https://www.privacy-regulation.eu/en/article-17-right-to-era...

Again, you do not have to if is business critical and used for fraud prevention. You must routinely delete logs before they get too old (60-90 days maybe), but you do not need to take special action beyond that. I’m not saying the GDPR isn’t troublesome, but having spent the better part of the last 6 months combing through the law and interpretations of it, I think the concern over IP addresses in log files that can…

You'd also have to argue why you need to store the IP and not just a hash of the IP if it's just for fraud prevention.

Re: How GDPR Will Change The Way You Develop

#606

Post by OrganicMSG »

icebraining wrote: post #557
OrganicMSG wrote: post #483

Earlier quoted context omitted.

How does this work out for Git repos and other things with encryption backed histories? If I run a software project and a developer wants an identifying section of a repo back-edited, do I have to edit and rebase the whole repo, and what does this do to the trust in a project that is based on a verifiable history? Also, I can't help but notice that currently there is a hell of a lot of money being bet on immutable pu…

Why are you accepting PII into your software projects' source repository in the first place?

The simple logical answer to that is that it is clearly impossible to blacklist.

The more specific answer is:

git config --global user.name "Your Name Comes Here"

git config --global user.email you@yourdomain.example.com

Also, looking up, you can undo a rebase with reflog, so even editing commits with an interactive rebase may not be enough to purge a git repo of identifiable information that people have entered.

Re: How GDPR Will Change The Way You Develop

#607

Post by 77pt77 »

danieltillett wrote: post #474
77pt77 wrote: post #280

Earlier quoted context omitted.

So a US company providing services to a US naturalized citizen in the US that is also a dual citizen of a country in the EU makes the company liable to follow these regulations? That makes no sense. This sounds unenforceable.

It is not citizenship, but residency. Yes the regulations make no sense and they really aren’t enforceable outside of the EU.

> It is not citizenship, but residency.

I think it's both.

Re: How GDPR Will Change The Way You Develop

#608

Post by kasey_junk »

chopin wrote: post #565
kasey_junk wrote: post #458

Earlier quoted context omitted.

How does one avoid people making web requests originating in Europe from reaching your servers else where? The obvious answer is by geographically identifying them by IP. Which GDPR makes pains to point out is personal data.

So you don't store data from that IP? How is this a problem? And that's perfectly compliant with the GDPR. It seems you can't be bothered to not store data.

You don’t see the humor (at least) of a privacy regulation requiring me to learn more about the consumers hitting the site? Previously they were so private I knew nothing but an IP.

Now I’m instrumenting my systems with geo lookup databases which usually also include much more fine grained data (such as home/business) than that.

In any case, your original point was to just not interact with those people, which requires active filtering and isn’t the same thing as saying ‘just don’t watch that tv show’ in that it demands actions on my part due to behaviors and preferences on someone else’s.

Re: How GDPR Will Change The Way You Develop

#609

Post by fleetingmoments »

ncallaway wrote: post #485
boredatwork wrote: post #325

Earlier quoted context omitted.

Sure I delete files that I don't like, but I don't typically rewrite all my old backups to purge them from there too.

This is my biggest question about HIPAA and GDPR about deleting specific user records and data. How are others planning on deleting data from all backups. It seems like any automatic process that modifies all existing backups has the potential to accidentally corrupt all backups in the process. Is there any safe way to safely delete a record out of my prior database snapshots, or is there a reason I don't actually ne…

What if you're using an append-only log, like Kafka as your data backbone?

Re: How GDPR Will Change The Way You Develop

#610

Post by PeterisP »

njl wrote: post #494
nrjames wrote: post #476

Earlier quoted context omitted.

Standard server logs with IP addresses must be disclosed in a privacy policy but you do not have to seek consent for them because you collect them as part of a business critical need to prevent fraud. See Recital 47, which includes the language: "The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned." https://www…

The user can request I delete all of the data related to them without “undue delay”. Are you ready to purge all references to certain IP addresses in your logs? Don’t forget backups. GDPR blows up a lot of assumptions we make about writing software and managing servers. https://www.privacy-regulation.eu/en/article-17-right-to-era...

Look at the paragraph you're quoting - you have to comply with the request if "one of the following applies", which means:

1) if you have a legitimate reason that allows you to process the data without consent (which would be the expected scenario; if not, then any sane organization would likely just choose to don't have that data in their logs at all), then none of the following applies, and you can refuse the request;

2) if you had a legitimate reason but "the personal data are no longer necessary", then you must comply.... but that's just duplication, you should not have had that data anymore since if you're compliant, you should have cleared the data out already. E.g. if you believe that you need (and are allowed) to store data for 6 months for purpose X; then you'd ignore the request for 5 month old data as you need it, and ignore the request for 7 month old data as you already purged it as a routine operation.

3) if you didn't have a legitimate reason and actually needed consent, then you follow the same process as you do for scrubbing references to all IP addresses which didn't give you consent. If you're compliant with the other requirements (which is tricky in this case), then the deletion request doesn't add anything meaningfully different.

Post reply on HN